{
 "site": "https://coreyjames.ai",
 "person": {
  "@type": "Person",
  "name": "Corey James",
  "jobTitle": "AI systems architect / Research engineer",
  "url": "https://coreyjames.ai/",
  "image": "https://coreyjames.ai/assets/brand/portrait-512.jpg",
  "sameAs": [
   "https://www.linkedin.com/in/coreyjamesai/",
   "https://letsfafo.com/",
   "https://meetfafo.com/"
  ],
  "knowsAbout": [
   "Governed autonomous engineering",
   "Bigger models and longer context on fixed GPU memory",
   "AI teammates inside Microsoft Teams and team chat",
   "Business systems as safe agent tools",
   "High-throughput batch inference and embeddings",
   "Custom small models for tool calling and routing",
   "Memory and code intelligence for agents",
   "Voice agents in calls and meetings",
   "GPU vector search and corpus analytics",
   "AI subscriptions as governed workers",
   "ACME",
   "Admission control and rate limiting",
   "Agent Client Protocol (ACP)",
   "Agent tool qualification testing",
   "Agent tool-execution safety and sandboxing",
   "Append-only log and journal design",
   "Application security hardening and threat modelling",
   "Applied cryptography",
   "Approximate nearest-neighbour search",
   "Axum",
   "Bash",
   "Binary wire protocol design",
   "Budget enforcement and cost governance",
   "Business-provider APIs rebuilt as governed agent tools",
   "C#",
   "C++",
   "CBOR",
   "CPU reference implementations and GPU equivalence testing",
   "CUDA C++",
   "CUDA Driver API",
   "CUTLASS",
   "Cache synchronisation and leader election",
   "Capacity engineering, backpressure and load testing",
   "Cargo",
   "Catalog versioning and drift detection",
   "Chrome extensions (Manifest V3)",
   "Cloudflare Tunnel",
   "Cloudflare Workers",
   "Cluster-health metrics on the GPU",
   "Code generation and metaprogramming",
   "Code graph and static dependency analysis",
   "ComfyUI",
   "Context engineering and persistent agent memory",
   "Contract-first interface design",
   "Conversational turn-taking and barge-in",
   "Cost attribution for AI work",
   "Credential brokering and secrets management",
   "Database performance diagnosis",
   "Declarative tool and agent definition",
   "Determinism and numerical reproducibility",
   "Distributed job orchestration",
   "Distributed-systems reliability",
   "Docker",
   "Evidence-gated API integration",
   "Evidence-gated acceptance",
   "Evidence-grounded LLM output",
   "FAISS",
   "FFmpeg",
   "FastAPI",
   "Federated compute provisioning",
   "GPU admission control and co-residency",
   "GPU inference engine engineering",
   "GPU memory management",
   "GPU numerical kernel design",
   "GPU profiling and tracing",
   "Garnet",
   "Gaussian-kernel cluster analysis",
   "Git",
   "GitLab",
   "Governed AI-assisted software engineering",
   "Grafana",
   "Grammar-constrained decoding",
   "GraphQL",
   "H.264",
   "Handlebars",
   "Hidden-state extraction",
   "Hugging Face Hub",
   "Hugging Face Text Embeddings Inference",
   "Hugging Face Transformers",
   "Hybrid retrieval",
   "Idempotency, exactly-once effects and crash recovery",
   "Identity and access management for AI agents",
   "Independent verification and adversarial review",
   "Intel Arc GPUs",
   "Intel oneAPI",
   "JSON Schema",
   "JSON Web Token (JWT)",
   "JSON-RPC",
   "JavaScript",
   "KV-cache engineering",
   "LD_PRELOAD symbol interposition",
   "LLM fine-tuning",
   "Large-scale GPU data pipelines",
   "Large-scale refactoring with parity proof",
   "Lease-based work claiming",
   "Link-time plugin registration",
   "Linux security primitives",
   "Lua",
   "MCP tool design",
   "ML evaluation methodology",
   "Mattermost",
   "MessagePack",
   "Meta Graph API",
   "Microsoft Agent 365",
   "Microsoft Azure",
   "Microsoft Copilot Studio",
   "Microsoft Entra ID",
   "Microsoft Graph",
   "Microsoft Teams",
   "Microsoft real-time media SDK",
   "Model Context Protocol (MCP)",
   "Model families and types",
   "Model quantization",
   "Multi-agent system architecture and orchestration",
   "Multi-vendor LLM integration",
   "Multilingual embedding model",
   "NGINX",
   "NVIDIA Blackwell GPUs",
   "NVIDIA Nsight Systems",
   "NVIDIA TensorRT",
   "NVIDIA TensorRT-LLM",
   "NVMe (cold-tier storage)",
   "Network egress confinement",
   "OAuth 2.0",
   "ONNX Runtime",
   "Observability and alerting",
   "OpenAI-compatible API",
   "OpenAPI",
   "Performance engineering and benchmarking",
   "Policy-as-code enforcement",
   "PostgreSQL",
   "PostgreSQL bulk-update engineering",
   "Prometheus",
   "Prompt-injection-aware tooling",
   "Provider-terms compliance in model routing",
   "Public environmental data APIs",
   "PyO3",
   "PyTorch",
   "Python",
   "React",
   "Real-time audio pipeline engineering",
   "Reddit",
   "Redis",
   "Reranker model",
   "Research data forensics",
   "Reversible infrastructure mutation",
   "RunPod",
   "Rust",
   "SQL",
   "SQLite",
   "SYCL",
   "Schema and migration discipline",
   "Schema-agnostic data access and SQL-injection defence",
   "Schema-driven build-time code generation",
   "Site reliability engineering",
   "Speech recognition model",
   "Speech synthesis model",
   "State-machine design for multi-agent workflows",
   "Static analysis as tests",
   "Streaming statistics in CUDA",
   "Synthetic training-data generation",
   "TLS and mTLS",
   "Text embedding models",
   "Tiled pairwise kernels",
   "Token-aware GPU batch scheduling",
   "Tokio",
   "TypeScript",
   "Unix domain sockets",
   "Vendor-integration reverse engineering",
   "Web crawling and document extraction",
   "WebAuthn",
   "WebSocket",
   "Webhook ingestion and verification",
   "Write-behind persistence",
   "X API",
   "YAML",
   "Zero-inbound network exposure",
   "oneDNN",
   "pgvector",
   "pybind11",
   "ratatui",
   "rmcp (Rust MCP SDK)",
   "sqlx",
   "systemd",
   "tmux",
   "tree-sitter",
   "vLLM"
  ],
  "contact": "https://coreyjames.ai/about/#contact"
 },
 "scale": {
  "source_lines": 4038736,
  "commits": 5048,
  "languages": 12,
  "systems": 10,
  "stories": 90,
  "ideas": 15,
  "capabilities": 10,
  "technologies": 177,
  "mcp_tools": 517,
  "patent_applications": 5
 },
 "mcp": "https://coreyjames.ai/mcp",
 "pages": [
  {
   "url": "https://coreyjames.ai/research/family-five-verifiable-ai-action-and-tool-synthesis/",
   "kind": "patent-family",
   "title": "Family Five: Verifiable AI action, tool synthesis and governance",
   "subtitle": "Every action is authorised, every output is observed, every result is verifiable; AI cannot self-authorise a tool.",
   "systems": [
    "fafo-core"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "5",
     "label": "conditions a tool must meet before it can be synthesised"
    },
    {
     "value": "8",
     "label": "fields in every evidence-ledger entry, lineage among them"
    },
    {
     "value": "4",
     "label": "result classes, assigned from observed evidence"
    },
    {
     "value": "6",
     "label": "layers of governance around each action"
    }
   ],
   "lede": "Methods and Systems for Evidence-Gated Synthesis and Governance of Agent-Callable Application Programming Interface Tools, and for Reconciled Execution of Mutations Against Ephemeral Third-Party Application Programming Interfaces. U.S. Provisional Patent Application No. 64/148,105 (patent pending). Embodied in the API integration platform of FAFO Core and Function Forge. Unconstrained AI invents tools or actions, acts outside intent, returns unverified results, and is hard to audit. This invention puts every action through one governed pipeline, from the intent that asks for it to an observation that must prove its result. A tool only with positive observation A tool may be synthesised only when five conditions hold. The one that does the work is the second: for every output field of the tool there",
   "quote": "No action can run outside the contract, and the AI cannot change the rules.",
   "evidence": [
    "Tool synthesis and governed API integration: an agent-callable tool synthesised only when 5 conditions hold, including a positive observation method for every output field.",
    "Evidence-gated acceptance: results placed in 4 classes from observed evidence, never from the model's own account, and complete only when every required field is observed.",
    "Audit trails for AI actions: an evidence entry with 8 fields for every action, including intent, observation and lineage to the entry it came from.",
    "Sandboxing and execution contracts: each action confined to a contract fixing inputs, allowed tools, outputs, observation methods and limits, inside 6 nested layers of governance.",
    "Patent filing for AI systems: U.S. Provisional Patent Application No. 64/148,105 (patent pending) on evidence-gated synthesis and governance of agent-callable API tools."
   ],
   "application_number": "64/148,105",
   "status": "provisional patent application, patent pending"
  },
  {
   "url": "https://coreyjames.ai/research/family-four-self-verifying-vector-substrate/",
   "kind": "patent-family",
   "title": "Family Four: Self-verifying vector and GPU retrieval substrate",
   "subtitle": "Same data, same result, verifiable at every step: every index proves it was built from the database it serves.",
   "systems": [
    "inference-fabric"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "8",
     "label": "properties bound into every index's attestation"
    },
    {
     "value": "4",
     "label": "checks: build, persist, publish and load"
    },
    {
     "value": "≤ 1",
     "label": "active generation per index at any moment"
    },
    {
     "value": "1 → 2",
     "label": "one GPU read per member vector, two computations from it"
    }
   ],
   "lede": "Methods and Systems for a Self-Verifying Deterministic Vector Index and GPU Retrieval Substrate Materialized From a Relational System of Record. U.S. Provisional Patent Application No. 64/148,001 (patent pending). Embodied in the vector store of the Inference Fabric. One authoritative source Traditional vector pipelines create multiple copies of data, a source database, a vector store, index files, GPU memory, with no provable link between them. Data can drift, go stale or be corrupted, and nobody can prove what produced a result. Here the relational database is the only authority. Vectors are exported deterministically into memory-mapped shards that serve reads and carry references back to the database; they are serving representations, never another authoritative copy. design <figure class=\"dv-figure\" aria-label=\"The system of record",
   "quote": "Every boundary is identifiable, verifiable, or refused.",
   "evidence": [
    "Vector search and ANN indexes: vectors exported deterministically from a relational database, the only authority, into memory-mapped shards; the same inputs, parameters, seed, format and implementation give a byte-identical index body.",
    "Data provenance for retrieval: every index bound to its source data and build conditions by one binding hash over 8 properties, including shard identifiers, generations, row counts, content hashes and journal positions.",
    "Fail-closed artifact pipelines: 4 checks at build, persist, publish and load, where a mismatch between disk and memory is a refusal, and at most 1 active generation per index so readers never see a torn set.",
    "Embedding analytics and cluster metrics: each member vector read from GPU memory once to feed 2 computations, the similarity score and cluster-health metrics from mean and mean squared distance to the centroid.",
    "GPU memory management: GPU residency keyed by data generation, evicting only the artifacts a change affected and never the whole cache."
   ],
   "application_number": "64/148,001",
   "status": "provisional patent application, patent pending"
  },
  {
   "url": "https://coreyjames.ai/research/family-one-deterministic-external-governance/",
   "kind": "patent-family",
   "title": "Family One: Deterministic external governance of autonomous AI work",
   "subtitle": "The AI never decides what it is allowed to do, what step it is on, or whether it is finished. External deterministic rules do.",
   "systems": [
    "agentos"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "9",
     "label": "states each action can be in"
    },
    {
     "value": "326",
     "label": "actions active at once in one busy work order"
    },
    {
     "value": "2,000",
     "label": "work orders the platform runs at the same time"
    },
    {
     "value": "52",
     "label": "legal transitions in the whole governance map"
    }
   ],
   "lede": "Systems and Methods for Structurally Enforced Governance of Autonomous AI Agents. U.S. Provisional Patent Application No. 64/146,881 (patent pending). Embodied in AgentOS. Authority outside the model The model is a nondeterministic worker inside a deterministic authority system. It does the work; it never decides what it is allowed to do, what step it is on, or whether it is finished. External rules, mathematics and database state decide all of that, and they decide it the same way every time. design <figure class=\"dv-figure\" aria-label=\"Each step: the model works, the external engine decides whether the next action is allowed, and only then does it happen\" <span class=\"eyebrow\" One step of autonomous work</span <div style=\"display: grid; grid-template-columns: 9rem minmax(0, 1fr); gap: 0.5rem 0.8rem;",
   "quote": "Completion is evidence-based; the AI never self-declares it.",
   "evidence": [
    "Multi-agent governance: autonomous AI work governed by external deterministic rules that decide what the model may do, what step it is on and whether it is finished.",
    "State-machine design for AI agents: a governance map of 52 legal transitions over actions in 9 states, constraining moves instead of enumerating a space of 326 concurrent actions.",
    "Evidence-gated acceptance: every step evaluated deterministically into one of six verdicts, completion reached only on evidence and every refusal an answer with a reason.",
    "Scale analysis of agent state spaces: about 2,000 concurrent work orders, each with about 10 to the 311 arrangements, shown to be beyond enumeration or exhaustive testing.",
    "Patent filing for AI systems: U.S. Provisional Patent Application No. 64/146,881 (patent pending) on structurally enforced governance of autonomous AI agents."
   ],
   "application_number": "64/146,881",
   "status": "provisional patent application, patent pending"
  },
  {
   "url": "https://coreyjames.ai/research/family-three-unified-context-across-models/",
   "kind": "patent-family",
   "title": "Family Three: Unified context across AI models and knowledge systems",
   "subtitle": "One authoritative context. Many models. Many sources. No AI provider owns the truth.",
   "systems": [
    "helix"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "1",
     "label": "authoritative context fabric"
    },
    {
     "value": "6",
     "label": "kinds of source in that context"
    },
    {
     "value": "4",
     "label": "scope levels a participant is filtered by"
    },
    {
     "value": "0",
     "label": "AI providers that own the truth"
    }
   ],
   "lede": "Methods and Systems for Maintaining Unified Conversation Context Across Heterogeneous Reasoning Backends Using a Provider-Neutral Substrate and a Transcript Authority Decoupled From a Scoped Semantic Store. U.S. Provisional Patent Application No. 64/147,766 (patent pending). Embodied in the collaboration shell of Helix. One fabric instead of scattered sources Traditional AI systems inherit fragmented context from whichever tool or provider they happen to be using: conversations in one place, files in another, email, meetings and enterprise artifacts elsewhere, with no single complete view. This invention holds context in one authoritative context fabric that no provider owns, which any of many heterogeneous models can be grounded from. design <figure class=\"dv-figure\" aria-label=\"Scattered sources against one fabric\" <div class=\"dv-two\" <div <span class=\"eyebrow\" Fragmented</span <div style=\"display:",
   "quote": "Model memory is not system memory.",
   "evidence": [
    "Context engineering for LLMs: 1 authoritative, provider-neutral context fabric from which many heterogeneous models are grounded, so 0 AI providers own the truth.",
    "Retrieval and knowledge integration: context drawn from 6 kinds of source, conversations, files, email, meetings, enterprise artifacts and semantic knowledge.",
    "Access control for AI context: each participant filtered to its scope at one of 4 levels, system, project, work order or conversation, seeing only what it is authorised to see.",
    "Multi-model orchestration: grounding packets rebuilt from the shared fabric at the current scope and revision beside each provider's own continuity, degrading additively when a source is missing.",
    "Patent filing for AI systems: U.S. Provisional Patent Application No. 64/147,766 (patent pending) on unified conversation context across heterogeneous reasoning backends."
   ],
   "application_number": "64/147,766",
   "status": "provisional patent application, patent pending"
  },
  {
   "url": "https://coreyjames.ai/research/family-two-durable-work-and-lossless-recovery/",
   "kind": "patent-family",
   "title": "Family Two: Durable work, tombstones and lossless recovery",
   "subtitle": "No accepted work is lost, and no completed result is delivered twice, across a durable broker and GPU runtimes.",
   "systems": [
    "inference-fabric"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "5",
     "label": "states; every piece of work is in exactly one"
    },
    {
     "value": "1",
     "label": "durable tombstone marks a completion"
    },
    {
     "value": "4",
     "label": "outcomes for every item at reconciliation"
    },
    {
     "value": "6 M",
     "label": "queued items in the loss this design closed"
    }
   ],
   "lede": "Methods and Systems for No-Loss Work Reconciliation Between a Durable-Log Broker and Accelerator Inference Runtimes Using Consumer-Reported Hardware Residency. U.S. Provisional Patent Application No. 64/147,527 (patent pending). Embodied in the broker of the Inference Fabric. Five states, every piece of work in exactly one Every piece of work is in exactly one of five states at any time: durable storage, consumer memory, queued for GPU, running on GPU, or durably complete. At any instant all accepted work is the disjoint union of those five sets, so nothing is ever unaccounted for. design <figure class=\"dv-figure\" aria-label=\"All accepted work at one instant as five disjoint regions that together are the whole\" <span class=\"eyebrow\" All accepted work at one instant</span <div style=\"display: grid;",
   "quote": "A piece of work may execute more than once on GPUs, and the outside world observes its completion at most once.",
   "evidence": [
    "Exactly-once delivery and crash recovery: a model of 5 states in which every accepted piece of work is in exactly one, so all accepted work is always accounted for.",
    "Write-ordering and durability design: a tombstone persisted after the output and before the input is retired, so a retired input always means the result is stored.",
    "Distributed systems correctness: recovery as a classification into 4 outcomes, redispatching only unresolved work owned by a failed consumer and not resident on a survivor.",
    "Message broker and queue design: at-least-once execution on GPUs with at-most-once observable completion, the design that closed a 6 M-item queue loss and balanced the token count to zero.",
    "Patent filing for AI infrastructure: U.S. Provisional Patent Application No. 64/147,527 (patent pending) on no-loss work reconciliation between a durable-log broker and GPU runtimes."
   ],
   "application_number": "64/147,527",
   "status": "provisional patent application, patent pending"
  },
  {
   "url": "https://coreyjames.ai/research/innovations/",
   "kind": "research",
   "title": "Innovations",
   "subtitle": "",
   "systems": [],
   "technologies": [],
   "stats": [],
   "lede": "Most of what I build starts as a failure I could name precisely, and the fix usually turns into a mechanism I reuse somewhere else. This page lists those mechanisms system by system, each in a few sentences, with a link to the longer account where one exists. AgentOS Drift as working-memory overflow: Long agent runs failed the same way every time, because the lead agent had to hold the rulebook, the plan and every teammate's state in its head. I treated that as a memory problem and moved all of it into a durable control plane, so each agent receives a small, freshly generated job with a contract attached and carries nothing between jobs. Models become swappable and a",
   "quote": "",
   "evidence": [
    "Multi-agent governance: a durable control plane in PostgreSQL holding rules, plans and team state, so each agent gets a small generated job with a contract and a crash loses nothing that matters.",
    "Evidence-gated acceptance: jobs that count as finished only when a typed response carrying a matching one-time token returns, so self-reported completion has no effect.",
    "Separation of duties for AI work: builders, quality checkers, a facts-only gatekeeper, an adversarial check on a different vendor's model and a final closer as separate roles.",
    "Token-aware scheduling: a broker that packs items into shape-pure lanes by token geometry and orders delivery so shared prefixes stay hot in each GPU's cache.",
    "Exactly-once delivery and crash recovery: tombstones written in place on an append-only log, and in-flight work reconciled after a crash against what each GPU consumer reports it holds.",
    "CUDA kernel development: one GPU pass over shard-resident vectors returning nearest neighbours and thirty-eight cluster-health metrics, with search results byte-identical to search alone."
   ]
  },
  {
   "url": "https://coreyjames.ai/stories/why-long-agent-runs-fail/",
   "kind": "story",
   "title": "Why long agent runs fail",
   "subtitle": "Diagnosing agent drift as working-memory overflow, and building the control plane that holds the state instead",
   "systems": [
    "agentos"
   ],
   "technologies": [
    "Rust",
    "PostgreSQL",
    "JSON Schema",
    "Model Context Protocol (MCP)",
    "Agent hook systems",
    "Multi-agent system architecture",
    "systemd"
   ],
   "stats": [
    {
     "value": "246",
     "label": "work orders run under the control plane"
    },
    {
     "value": "45,097",
     "label": "state transitions, each with a receipt"
    },
    {
     "value": "31,811",
     "label": "metered usage entries tied to the work that spent them"
    }
   ],
   "lede": "Every long autonomous coding run I launched failed the same way. Somewhere past a horizon the lead agent lost a rule, a plan step or a teammate's state, and the work quietly diverged from what had been agreed. The common response is a longer, sterner prompt. I had done that, and it bought a few more hours before the same drift returned. So I named the failure for what it is, working-memory overflow, and built the control plane that follows from that name. AgentOS moves the state out of the model and into a database, makes every job small and freshly rendered, and enforces the rules with machinery. The challenge An AI coding agent given a day-long task has to",
   "quote": "If drift is memory overflow, the cure is less to remember.",
   "evidence": [
    "Agent orchestration: a PostgreSQL work graph holds every work order, task, decision and cost, and each agent gets a small contract-bound job rendered at dispatch, across 246 work orders.",
    "Diagnosing LLM agent drift: long-run failures named as working-memory overflow and answered by moving state out of the model, with recovery that rebuilds an agent's picture from the graph after a crash or compaction.",
    "Multi-agent governance: 106 hook modules across eleven lifecycle events turn policy into refusals, so the lead agent cannot re-type or edit an artifact.",
    "Control-plane and state-machine architecture: a Rust control plane of about 546,000 lines with 79 forward-only migrations, where 45,097 state transitions each left a receipt.",
    "Cost attribution for AI work: 31,811 metered usage entries tied to the work that spent them."
   ],
   "problem": "governed-agents"
  },
  {
   "url": "https://coreyjames.ai/stories/closed-by-evidence/",
   "kind": "story",
   "title": "Closed by evidence",
   "subtitle": "Building an API integration platform through gated AI work orders, and refusing to close it until every item had independent proof",
   "systems": [
    "agentos",
    "fafo-core"
   ],
   "technologies": [
    "Rust",
    "PostgreSQL",
    "Frontier coding models",
    "Shell conformance suites",
    "git",
    "Governed AI-assisted software engineering"
   ],
   "stats": [
    {
     "value": "23 of 23",
     "label": "close items with a current passing verdict from an independent reviewer"
    },
    {
     "value": "14 days",
     "label": "from opening the work order to closing it on evidence"
    },
    {
     "value": "4,297",
     "label": "state transitions across 13 agent seats"
    }
   ],
   "lede": "I built an API integration platform, about 20,000 lines of Rust across five crates, almost entirely through AI agent teams working under my governance system. When the agents reported it done, I did not close it. I required a passing, current verdict from an independent reviewer on every close item, and the system closed the work order only when the last one was in. In the meantime the close machinery had bugs of its own, and I fixed those under the same rules. The challenge An agent that says \"done\" is making a claim, and agents make that claim early and often. For a platform I intended to depend on, \"done\" had to mean something I could verify afterwards: every",
   "quote": "An override on day one of a governance system is the end of that system.",
   "evidence": [
    "Evidence-gated acceptance: an API integration platform closed only when 23 of 23 close items carried a current passing verdict from an independent reviewer, 14 days from opening to close.",
    "Rust systems engineering: an API integration platform of about 20,000 lines of Rust across five crates, built almost entirely by AI agent teams under my governance system.",
    "Technical leadership of agent teams: 4,297 state transitions across 13 agent seats, with builders from two model vendors and reviewers from a different family.",
    "Re-runnable acceptance testing: a phased plan gated B0 to B9, with thirty-five acceptance artefacts, each a script and a transcript.",
    "Governance system reliability: defects in the close path, closers that stalled and closers that ran away, fixed mid-delivery as governed work under the same rules."
   ],
   "problem": "governed-agents"
  },
  {
   "url": "https://coreyjames.ai/stories/separation-of-duties-for-ai-work/",
   "kind": "story",
   "title": "Separation of duties for AI work",
   "subtitle": "Independent gatekeepers, reviewers from a different vendor, and failures that stay failures",
   "systems": [
    "agentos",
    "agent-swarm"
   ],
   "technologies": [
    "PostgreSQL",
    "JSON Schema",
    "Frontier coding models",
    "Model Context Protocol (MCP)",
    "Separation-of-duties review design"
   ],
   "stats": [
    {
     "value": "27",
     "label": "gates audited in the eighth phase of the swarm build"
    },
    {
     "value": "2",
     "label": "failed gates kept as failures, not narrowed away"
    },
    {
     "value": "1",
     "label": "unrelated gate dropped by explicit decision"
    }
   ],
   "lede": "AI reviewers have two failure modes. Left alone they re-litigate forever. Drawn from the same model as the builder they share its blind spots and pass its mistakes. I applied the principle regulated industries use: the people who build do not judge, the judges are independent, and a failure stays a failure until it is fixed. In my system the builders, the quality reviewers, the gatekeeper and the adversarial reviewer are separate agents, the reviewers run on a different vendor's models from the builders, and a phase with two failed gates is held at a conditional pass with two failures. The challenge Agent teams report success. They are built to complete tasks and they complete the task of saying so.",
   "quote": "Adding a role would have let builders stop testing.",
   "evidence": [
    "Separation of duties for AI work: builders, quality reviewers, a gatekeeper and an adversarial reviewer as separate agents, with the reviewers on a different vendor's models from the builders.",
    "Evidence-gated acceptance: a phase audited against 27 gates held at a conditional pass, its 2 failed gates kept as failures and 1 unrelated gate dropped by explicit decision rather than by narrowing the criteria.",
    "Multi-agent governance: follow-up review scoped to the findings it was opened for so AI review converges, and a FAIL stays a FAIL until the fix is delivered and re-reviewed.",
    "Quality engineering for AI-produced work: checksums scrubbed from reviewer packets so reviewers reasoned about delivered content, and testing kept a developer activity that produces evidence rather than a new role."
   ],
   "problem": "governed-agents"
  },
  {
   "url": "https://coreyjames.ai/stories/tools-are-the-platform/",
   "kind": "story",
   "title": "Tools are the platform",
   "subtitle": "One frozen, tested pipeline for every action an agent takes, and catalogs that cannot drift between hosts",
   "systems": [
    "agent-swarm"
   ],
   "technologies": [
    "Rust",
    "Tokio",
    "YAML tool definitions",
    "JSON Schema",
    "PostgreSQL LISTEN/NOTIFY",
    "Redis",
    "Agent tool-execution safety"
   ],
   "stats": [
    {
     "value": "12",
     "label": "pipeline steps on every call, in an order frozen behind sign-off"
    },
    {
     "value": "40",
     "label": "declarative tools, plus Rust built-ins"
    },
    {
     "value": "50",
     "label": "golden fixtures; a tool without its fixtures fails the build"
    }
   ],
   "lede": "An agent that acts on real systems needs validation, authorisation, limits, secret scrubbing, audit and observation on every action. If each tool implements those itself, every new tool is a new hole. In my agent runtime every call, whatever the tool, passes through one frozen, ordered pipeline of twelve steps, and a tool contributes only its core behaviour. Most tools are declared in YAML. No tool enters the catalog without golden fixtures and attack fixtures, and the build fails if one is missing. The challenge Tools come in many kinds: shell commands, HTTP calls, compositions of other tools, calls to other agents. Local open-source models make malformed calls. Adding a tool has to stay cheap or the estate stops growing.",
   "quote": "Exceptions are where the holes are.",
   "evidence": [
    "Agent tool execution safety: every agent call passes one frozen pipeline of 12 steps covering validation, authorisation, limits, secret scrubbing, audit and observation; a tool supplies only its own behaviour.",
    "Declarative tool design: 40 declarative tools in YAML carrying their schema, limits and authorisation, plus Rust built-ins.",
    "Test-gated tool catalogs: 50 golden fixtures plus attack fixtures and shell-injection fixtures; a tool without its fixtures fails the build.",
    "Distributed configuration consistency: hash-pinned tool catalogs with drift detection over database notifications, falling back to polling under measured saturation thresholds with hysteresis.",
    "Least privilege for AI agents: an agent can call only the tools its persona was given."
   ],
   "problem": "governed-agents"
  },
  {
   "url": "https://coreyjames.ai/stories/a-coding-agent-that-never-holds-the-keys/",
   "kind": "story",
   "title": "A coding agent that never holds the keys",
   "subtitle": "A sandboxed agent on a local open-source model that edits, tests and proposes changes without a repository credential",
   "systems": [
    "agent-swarm"
   ],
   "technologies": [
    "Rust",
    "Docker",
    "Redis Streams",
    "Signed message envelopes",
    "Open-source models on vLLM",
    "GitLab API"
   ],
   "stats": [
    {
     "value": "0",
     "label": "agent commits or merge requests against the main repository"
    },
    {
     "value": "2",
     "label": "full runs through edit, test, commit, push and merge request"
    },
    {
     "value": "1",
     "label": "failing-test run that stopped without pushing, scored as a pass"
    }
   ],
   "lede": "A coding agent running on a local open-source model edited code in a throwaway container, ran the tests, committed, pushed, and a merge request appeared for human review. The agent never held the repository credential and had no path to the main branch. A second, long-lived agent checked the request and opened the merge request on its behalf. The challenge Autonomous coding agents are useful in proportion to what they can touch, and dangerous in the same proportion. The usual compromise hands the agent a scoped token and hopes. I wanted a design where the worker could do everything a developer does up to the point of proposing a change, and could not do the one thing that matters: write",
   "quote": "An impressive open-ended demo would have proved less.",
   "evidence": [
    "Least-privilege design for autonomous coding agents: a worker on a local open-weight model edits, tests and pushes its own branch with no repository credential; 0 commits or merge requests against the main repository.",
    "Sandboxing and container hardening: the worker runs in a throwaway container destroyed after the run, on a model served through vLLM on my own hardware.",
    "Gatekeeper pattern for AI agents: a separate long-lived agent holds the credential, checks the worker's request and opens the merge request for human review, across 2 full runs.",
    "Honest acceptance testing for AI agents: 1 failing-test run that stopped without pushing was scored as a pass, because the security property was what the test measured."
   ],
   "problem": "governed-agents"
  },
  {
   "url": "https://coreyjames.ai/stories/a-self-hosted-colleague-in-a-teams-call/",
   "kind": "story",
   "title": "A self-hosted colleague in a Teams call",
   "subtitle": "Bridging Microsoft's real-time media stack to a voice AI that never leaves my own hardware",
   "systems": [
    "helix"
   ],
   "technologies": [
    "C# / .NET 8",
    "Microsoft real-time media SDK",
    "Azure",
    "Rust",
    "Tokio",
    "WebSocket binary protocols",
    "Audio pipeline engineering",
    "Speech recognition model",
    "Speech synthesis"
   ],
   "stats": [
    {
     "value": "50.001/s",
     "label": "buffers per second across the soak, against 20 ms pacing"
    },
    {
     "value": "250 ms",
     "label": "the single retry in a forced mid-call reconnect"
    },
    {
     "value": "67 ms",
     "label": "round-trip media latency at most in a single probe, 65 at least"
    }
   ],
   "lede": "I rang a Microsoft Teams number, a digital employee answered, and we had a two-way spoken conversation. The speech recognition, the conversation engine and the voice all ran on GPUs in my own rack. Nothing about the call touched a third-party AI cloud. Making that possible meant building a bridge between two worlds that were never designed to meet: Microsoft's Windows-only real-time media stack and a Linux voice engine, joined by a purpose-built audio link that survived a thirty-minute soak and a forced mid-call reconnect before I would call it done. The challenge Microsoft Teams will hand raw call audio to a bot, and only to a Windows application built on Microsoft's real-time media SDK. My voice engine, with its",
   "quote": "Replaying produces a colleague who answers a question from twenty seconds ago.",
   "evidence": [
    "Microsoft Teams real-time media: a self-hosted AI colleague in Teams calls through a Windows media bridge on Azure, carrying 20 ms buffers at 50.001 per second with no receive stalls.",
    "Binary wire protocol design: one authenticated full-duplex audio link per call, implemented in C# and in Rust and proven byte-identical against golden test vectors.",
    "Distributed systems correctness: a forced mid-call reconnect resumed the same call after a single 250 ms retry, dropping audio from the gap instead of replaying it.",
    "Real-time voice AI on local GPUs: recognition, conversation and voice kept on my own hardware behind the engine's existing audio seam, with 65 to 67 ms round-trip media latency."
   ],
   "problem": "voice"
  },
  {
   "url": "https://coreyjames.ai/stories/solving-the-digital-employee-identity/",
   "kind": "story",
   "title": "Solving the digital-employee identity",
   "subtitle": "Working out, from real tenant evidence, how an AI employee can legitimately answer, call and act inside Microsoft 365",
   "systems": [
    "helix"
   ],
   "technologies": [
    "Microsoft Graph",
    "Entra Agent ID",
    "Agent 365",
    "C#",
    "Rust",
    "Certificate credentials",
    "Identity and access management for AI agents"
   ],
   "stats": [
    {
     "value": "3",
     "label": "Microsoft principals, each with permissions the others lack"
    },
    {
     "value": "1",
     "label": "native media platform, owned by a transport-only client"
    }
   ],
   "lede": "Microsoft's Agent 365 lets an organisation give an AI a real identity in its tenant: a digital employee that can be called, join meetings and act under its own name. Making one actually do those things involves three different Microsoft principals, some combinations the platform rejects, and behaviour the documentation did not yet cover. I probed the real tenant, captured what the wire said, and composed the paths that work. The employee answers calls, joins meetings and shares its screen. The challenge An identity that can answer an inbound call is not necessarily one that can place an outbound call, own a media session, or act in a meeting. Microsoft exposes the application identity, the agent identity and the calling",
   "quote": "An identity layer that spoofs is not an identity layer.",
   "evidence": [
    "Identity for AI agents in Microsoft 365 and Entra: a digital employee composed from 3 Microsoft principals, each job given to the principal the tenant itself proved could do it.",
    "Credential isolation for AI agents: the model asks for an action while the server mints and checks employee-scoped Graph tokens, so no token reaches the model.",
    "Microsoft Graph integration: an employee that answers calls, joins meetings, chats, presents and calls on raised hands under its own name.",
    "Evidence-led platform engineering: identity paths settled by probing the tenant and keeping the wire traffic where the documentation stopped."
   ],
   "problem": "collaboration"
  },
  {
   "url": "https://coreyjames.ai/stories/a-meeting-attendee-that-will-not-fake-it/",
   "kind": "story",
   "title": "A meeting attendee that will not fake it",
   "subtitle": "An AI participant that chats, presents slides and shares a screen in Teams, and says plainly what the platform will not let it do",
   "systems": [
    "helix"
   ],
   "technologies": [
    "Rust MCP server",
    "Microsoft Graph",
    "Teams meeting-stage apps",
    "Node.js",
    "Headless Linux desktops",
    "FFmpeg and H.264",
    "C#"
   ],
   "stats": [
    {
     "value": "13",
     "label": "meeting actions, each with an exact schema"
    },
    {
     "value": "1",
     "label": "action that refuses by design: raising its own hand"
    },
    {
     "value": "55 of 55",
     "label": "unit tests passing before a real meeting had proved the tools"
    }
   ],
   "lede": "I wanted the digital employee to be a useful participant in a Teams meeting: follow the chat, put slides on the stage and drive them, notice who has a hand up and call on them, share a terminal or a browser so people can watch it work. It does all of that. It does not raise its own hand, because Microsoft's platform offers no supported way for it to, and I built that as an honest refusal instead of reporting a hand raised from local state. The challenge Meeting participation is many small capabilities, each with its own platform seam, and some of those seams do not exist. Native PowerPoint Live exposes no control or event hooks. The hand-raise state",
   "quote": "Tests that pass are not a meeting that worked.",
   "evidence": [
    "MCP server design: 13 meeting actions for an AI participant in Teams, each with an exact schema, acting as one named employee.",
    "Evidence-gated acceptance: an action counts as done only once proven in a real meeting, not when its 55 of 55 unit tests pass.",
    "Screen sharing from Linux agents into Teams: a headless desktop captured as H.264 frames and published into the meeting through a Windows media bridge.",
    "Honest failure design for AI agents: the one action the platform does not support, raising its own hand, returns a named refusal instead of a fake."
   ],
   "problem": "collaboration"
  },
  {
   "url": "https://coreyjames.ai/stories/agents-with-real-tools-and-no-keys/",
   "kind": "story",
   "title": "Agents with real tools and no keys",
   "subtitle": "A governed gateway that lets AI agent teams use payments, email and social-publishing services with every action attributed and no credential in any agent",
   "systems": [
    "fafohive",
    "agentos"
   ],
   "technologies": [
    "Rust",
    "Model Context Protocol (MCP)",
    "OAuth 2.0 and JWT",
    "PostgreSQL",
    "Webhook signature verification",
    "TypeScript"
   ],
   "stats": [
    {
     "value": "~350",
     "label": "vendor operations visible to managed agents, each rebuilt as my own tool"
    },
    {
     "value": "0",
     "label": "credentials held by any agent"
    },
    {
     "value": "2 hosts",
     "label": "attribution and webhook delivery proven end to end"
    }
   ],
   "lede": "I wanted AI agent teams to run small experimental businesses: take payments, send email, publish to social platforms. The moment you hand an agent a vendor API key you have three problems. The key leaks into logs. You cannot say afterwards which assignment created which customer or post. And the vendor's events, a payment, a reply, a bounce, have no way back to the team that caused them. I built one governed gateway between agents and vendors that solves all three. It exposes several hundred vendor operations to managed agents, every one attributed, with no agent ever holding a key. The challenge Each provider publishes an API for exactly these services. Handing an agent a client for it is easy",
   "quote": "Attribution that might be silently dropped is worse than none.",
   "evidence": [
    "Governed API integration for AI agents: one gateway exposing ~350 vendor operations, each rebuilt from the provider's API as my own tool, with 0 credentials held by any agent.",
    "Identity architecture for AI agents: identity derived from the authenticated assignment, never from tool arguments, so an agent cannot act or bind a website for another business.",
    "Exactly-once delivery and crash recovery: durable accounting around every provider call, so a restart never repeats a charge or loses track of one.",
    "Data attribution and provenance: attribution stamped into a vendor payload only where that operation and API version round-trips it, otherwise kept on my side; proven end to end on 2 hosts.",
    "Webhook ingestion and routing: signed vendor events returned in frozen batches to the mailbox of the team lead whose assignment caused them."
   ],
   "problem": "governed-agents"
  },
  {
   "url": "https://coreyjames.ai/stories/a-code-explainer-that-is-not-allowed-to-invent/",
   "kind": "story",
   "title": "A code explainer that is not allowed to invent",
   "subtitle": "Compute the call graph first, narrate second: putting deterministic evidence in front of the model",
   "systems": [
    "fafohive"
   ],
   "technologies": [
    "Rust",
    "tree-sitter",
    "PostgreSQL",
    "Redis",
    "Code graph analysis",
    "Embedding models"
   ],
   "stats": [
    {
     "value": "294,033",
     "label": "of 294,362 code chunks covered by the graph"
    },
    {
     "value": "0",
     "label": "model calls in a dependency trace"
    },
    {
     "value": "19,000",
     "label": "files, several languages, in the indexed monorepo"
    }
   ],
   "lede": "Ask a language model how a piece of code works and it will tell you, fluently, including call paths that do not exist. Engineers act on those answers. I built a code-intelligence service where the model may only describe edges that a computed graph has already proven. The graph is extracted from source with a parser, dependency traces are plain database traversals with no model involved, and the explainer narrates only the evidence it is handed. If the graph's coverage is incomplete for a query, the answer is \"coverage incomplete\". The challenge A monorepo of around 19,000 files across several languages, used daily by AI agents that must understand blast radius before changing a symbol. The service had to be",
   "quote": "A refusal beats a plausible guess, because the caveat is the first thing a reader stops seeing.",
   "evidence": [
    "Code intelligence for AI agents: a tree-sitter call graph over a 19,000-file multi-language monorepo, with 294,033 of 294,362 code chunks covered.",
    "Hallucination prevention by design: the model narrates only a path the graph has proven, and a query the graph cannot fully cover returns coverage incomplete instead of a guess.",
    "Graph queries in SQL: dependency tracing as a bounded breadth-first search over partitioned edge tables, with 0 model calls in a trace.",
    "Index lifecycle design: edges move from pending to active as their endpoints are indexed, and graph generations let the index rebuild without serving a half-built graph."
   ],
   "problem": "governed-agents"
  },
  {
   "url": "https://coreyjames.ai/stories/a-hundred-tokens-instead-of-forty-two-thousand/",
   "kind": "story",
   "title": "A hundred tokens instead of forty-two thousand",
   "subtitle": "Compiling an agent's tool catalog into a 0.6-billion-parameter model that cannot invent a tool",
   "systems": [
    "capabilities-model"
   ],
   "technologies": [
    "Rust",
    "CUDA",
    "PyTorch",
    "Hugging Face Transformers",
    "Model fine-tuning",
    "Grammar-constrained decoding",
    "Model Context Protocol (MCP)",
    "vLLM",
    "NVIDIA Blackwell GPUs"
   ],
   "stats": [
    {
     "value": "0.955",
     "label": "recall at 5; the strongest classical baseline scored 0.949"
    },
    {
     "value": "none",
     "label": "tool names outside the catalog, in any run"
    },
    {
     "value": "2,048",
     "label": "simultaneous clients in a burst, none failed or rejected"
    },
    {
     "value": "2.7 GiB",
     "label": "engine memory on the card the 30B model already uses"
    }
   ],
   "lede": "An agent connected to a serious tool estate pays for that estate on every turn. The schema of every tool it might call is loaded into context whether it uses one or not. Measured on the wire, that cost was mine on every turn. I replaced the catalog with a single discovery tool backed by a 0.6-billion-parameter model that has the catalog memorised and cannot name a tool that does not exist. The model's recall matches the strongest retrieval baseline I could build, and that tie is published beside it. The challenge Two failures, both expensive. The standing tax: every tool an agent can reach is described to it on every request, so a rich estate makes every turn slower",
   "quote": "The baseline was weak. I struck the comparison.",
   "evidence": [
    "LLM fine-tuning for tool discovery: a 0.6-billion-parameter model fully fine-tuned on a corpus generated from the tool registry, rebuilt in minutes whenever the registry changes.",
    "Grammar-constrained decoding: a grammar compiled from the registry and applied during decoding, so no tool name outside the catalog was produced in any run.",
    "Context-window cost reduction for agents: an agent's whole tool catalog replaced by one discovery tool, about a hundred tokens of standing context in place of forty-two thousand.",
    "ML evaluation methodology: recall at 5 of 0.955 against 0.949 for the strongest classical baseline I could build, with the tie published beside the model.",
    "GPU inference on shared hardware: a CUDA decoding engine in 2.7 GiB on the card a 30B model already uses, serving a burst of 2,048 simultaneous clients with none failed."
   ],
   "problem": "small-models"
  },
  {
   "url": "https://coreyjames.ai/stories/the-baseline-that-tied-us/",
   "kind": "story",
   "title": "The baseline that tied us",
   "subtitle": "Retiring a flattering benchmark, building the strongest retriever I could, and publishing the result that hurt",
   "systems": [
    "capabilities-model"
   ],
   "technologies": [
    "Evaluation harness design",
    "BM25",
    "Embedding models",
    "ONNX Runtime",
    "Rust",
    "Pre-registered experiments"
   ],
   "stats": [
    {
     "value": "17",
     "label": "points of recall the first headline claimed, struck before publication"
    },
    {
     "value": "469",
     "label": "held-out queries, frozen before any model result was reported"
    },
    {
     "value": "5",
     "label": "embedding models in the bake-off for the baseline"
    }
   ],
   "lede": "My tool-discovery model had a headline: a large lead in recall over classical retrieval. The results were about to be written up and every incentive pointed at believing the number. I struck it. The comparison was against a weak baseline, and a weak baseline makes any model look good. I replaced it with the strongest classical retriever I could assemble. That retriever tied the model at the cutoffs that matter and beat it on long, buried requests. The tie is the number I publish. The challenge The first comparison for the capabilities model was against an external small tool-calling model whose results carried no information: anything would have won. The second was against a retrieval baseline that, on inspection, had",
   "quote": "A result I would not accept from someone else is a result I cannot publish.",
   "evidence": [
    "ML evaluation methodology: a 469-query held-out set frozen before any model result was reported, plus fifteen long, buried requests.",
    "Benchmark integrity: a 17-point recall headline struck before publication because its baseline had ranked two thousand entries against the model's forty-two.",
    "Hybrid retrieval baselines: a dense-plus-BM25 fusion retriever with every weight and cutoff chosen by sweep, which tied the model and beat it on buried requests.",
    "Embedding model selection: a bake-off of 5 embedding models that replaced an incumbent chosen by habit.",
    "Known-answer controls in experiment harnesses: a control that failed once stopped the whole matrix until a numerical precision setting was pinned and every ranker re-run."
   ],
   "problem": "proof"
  },
  {
   "url": "https://coreyjames.ai/stories/a-router-beside-a-production-model/",
   "kind": "story",
   "title": "A router beside a production model",
   "subtitle": "Serving two thousand concurrent agents from a 0.6B model in the memory left over on a shared GPU, and reporting the target I missed",
   "systems": [
    "capabilities-model"
   ],
   "technologies": [
    "CUDA",
    "Rust",
    "Unix-socket wire protocols",
    "Model Context Protocol (MCP)",
    "Admission control",
    "NVIDIA Blackwell GPUs"
   ],
   "stats": [
    {
     "value": "2.7 GiB",
     "label": "the engine's whole footprint beside a 30B model"
    },
    {
     "value": "85.9/s",
     "label": "requests served during the largest burst"
    },
    {
     "value": "0",
     "label": "answers failed, rejected or contaminated in that burst"
    }
   ],
   "lede": "The tool-discovery model had to live on a GPU whose memory belonged to a 30-billion-parameter serving model. I set two thousand concurrent clients as an acceptance requirement, and built an engine that admits work against measured memory and refuses with a number when it cannot. The sustained throughput target I had pre-registered for mixed traffic was missed by a wide margin, for a reason I can name, and that miss is on this page. The challenge A discovery model that agents call before most actions will be called by many agents at once. If it falls over under load, every agent stalls at the same moment. It had to serve a burst of thousands, never return a corrupted answer under",
   "quote": "The miss is structural, and saying so is more useful to the next design than a better-looking number.",
   "evidence": [
    "Inference serving architecture: a batched continuous-decode engine with paged key-value memory, 2.7 GiB in total beside a 30B model on one shared GPU.",
    "Admission control under memory pressure: requests admitted against measured free memory and refused as a typed busy response with a number when they do not fit.",
    "Load testing methodology: a ladder from one to 2,048 clients with abort conditions, 85.9 requests a second in the largest burst and 0 answers failed, rejected or contaminated.",
    "Capacity reporting: a pre-registered sustained throughput target for mixed traffic reported as missed, with its cause, instead of a friendlier accounting of about 14 requests a second."
   ],
   "problem": "small-models"
  },
  {
   "url": "https://coreyjames.ai/stories/bit-identical-across-batch-compositions/",
   "kind": "story",
   "title": "Bit-identical across batch compositions",
   "subtitle": "Designing nondeterminism out of a GPU decoder so an agent's choice of tool never depends on its neighbours",
   "systems": [
    "capabilities-model"
   ],
   "technologies": [
    "CUDA",
    "Rust",
    "Numerical reproducibility",
    "GPU kernel design"
   ],
   "stats": [
    {
     "value": "12 of 12",
     "label": "bit-identity gates across batch compositions"
    },
    {
     "value": "2,345",
     "label": "of 2,345 shuffled compositions agree on the top result"
    },
    {
     "value": "484",
     "label": "of 484 ranked lists match an independent implementation"
    }
   ],
   "lede": "Under continuous batching, the same request can return a different answer depending on what else is in the batch. For most workloads that is noise. For a model whose job is to tell an agent which tool to call, it is a correctness bug: the ranking must not depend on strangers. I set a gate that top results must be stable across batch compositions, then went further and built the decoder so that its output bits are identical whatever else is in the batch. The challenge GPU reductions are fast because they are parallel, and parallel floating-point sums are order-dependent. Different batch sizes choose different tiling, different tiling changes summation order, and the last bits of a logit shift. Here,",
   "quote": "A faster decoder that sometimes picks a different tool is slower at the job.",
   "evidence": [
    "Deterministic GPU computation: a CUDA decoder whose output bits are identical whatever else is in the batch, passing 12 of 12 bit-identity gates.",
    "CUDA kernel development: one block per output row and fixed-order reductions, a 32-lane shuffle tree under a 256-thread tree, with no K-split tiling.",
    "Numerical reproducibility and bitwise validation: 2,345 of 2,345 shuffled compositions agree on the top result, and 484 of 484 ranked lists match an independent implementation.",
    "Inference correctness under continuous batching: serial and batched engines share one set of row kernels, held by a header invariant so the two cannot drift apart."
   ],
   "problem": "proof"
  },
  {
   "url": "https://coreyjames.ai/stories/trying-the-industrial-path-first/",
   "kind": "story",
   "title": "Trying the industrial path first",
   "subtitle": "Evaluating the standard vendor serving stack for a custom decoder, and closing that path on measurements",
   "systems": [
    "capabilities-model"
   ],
   "technologies": [
    "TensorRT-LLM",
    "Grammar-constrained decoding",
    "CUDA",
    "NVIDIA Blackwell GPUs"
   ],
   "stats": [
    {
     "value": "4",
     "label": "checks on the vendor path, any one of which could have kept it"
    },
    {
     "value": "3",
     "label": "guarantees any engine had to keep: identical answers, no repeats, catalog names only"
    },
    {
     "value": "1,000×",
     "label": "weight corruption on some tensors after the vendor conversion"
    }
   ],
   "lede": "When the tool-discovery model needed to serve two thousand concurrent clients, the obvious answer was the vendor's industrial serving stack. I directed that it be tried first, before any custom engine was justified. It was traced to its extension point in source, probed against my decoding constraints, and measured in the vendor's own container. It did not fit, for three reasons I could show, and the custom engine was kept. The challenge Building a custom GPU decoder is expensive and easy to justify badly. design <blockquote class=\"dv-quote\" <p If a standard stack would serve the model at the required concurrency with the required guarantees, the custom engine was the wrong choice however satisfying it was to build.</p </blockquote Constraints Identical",
   "quote": "If a standard stack would serve the model at the required concurrency with the required guarantees, the custom engine was the wrong choice however satisfying it was to build.",
   "evidence": [
    "Vendor stack evaluation: the vendor's industrial serving stack traced to its extension point in source, probed with the real constraint and measured in its own container before a custom engine was kept.",
    "TensorRT and TensorRT-LLM engineering: a conversion verdict that found weight corruption of 1,000 times on some tensors after the vendor conversion.",
    "Grammar-constrained decoding: probes of the stack's guided-decoding extension point showing the no-repeat constraint could not be enforced soundly.",
    "GPU performance benchmarking: a throughput ceiling study in the vendor's container, 492 requests a second with the card to itself against 56 beside the 30B model."
   ],
   "problem": "proof"
  },
  {
   "url": "https://coreyjames.ai/stories/rewriting-an-engine-extension-without-changing-a-token/",
   "kind": "story",
   "title": "Rewriting an engine extension without changing a token",
   "subtitle": "Porting a GPU serving layer from Python to native C++ with bit-identical output, and proving every remaining line of Python was required",
   "systems": [
    "activekv"
   ],
   "technologies": [
    "C++",
    "pybind11",
    "PyTorch ATen",
    "CPython C API",
    "vLLM",
    "SYCL / oneAPI",
    "Intel Arc GPUs",
    "Numerical reproducibility"
   ],
   "stats": [
    {
     "value": "13 of 13",
     "label": "exact-mode parity cells bitwise; 12 of 12 hybrid"
    },
    {
     "value": "0",
     "label": "Python files in the release payload"
    },
    {
     "value": "77,000",
     "label": "lines of C++ in 361 engine files"
    }
   ],
   "lede": "ActiveKV began life as Python inside vLLM. That was the right way to find out whether the design worked and the wrong way to deliver it: the per-token path was slow, and the product logic sat in readable source. I moved the whole runtime to native C++ in under three weeks. In every parity cell the output was bit-identical, and a line-by-line audit cites the exact framework contract behind the one place Python still dispatches. The challenge A port like this fails in two ways. It changes behaviour, which in an inference engine means a different token somewhere in a long generation that nobody notices until a customer does. Or it stops short, leaving a layer of Python glue that",
   "quote": "A framework interface requiring a Python function does not mean the implementation inside that function must be Python.",
   "evidence": [
    "C++ and native ports with parity proof: a vLLM extension moved from Python to native C++ with 13 of 13 exact parity cells bitwise and 12 of 12 hybrid.",
    "vLLM internals: a runtime layer inside vLLM's scheduler, worker and attention backend ported without changing those interfaces, 77,000 lines of C++ in 361 engine files.",
    "Python and C++ interoperability: an async protocol the defence said needed Python, implemented natively through the interpreter's C API.",
    "Technical leadership of agent teams: a seven-criterion definition of done and independent QA agents per module lane, with 0 Python files in the release payload.",
    "Code review policy for native boundaries: an intake review that rejects new Python modules, Python imports from C++ and per-step Python callbacks on the native path."
   ],
   "problem": "proof"
  },
  {
   "url": "https://coreyjames.ai/stories/proving-a-rewrite-is-the-same-system/",
   "kind": "story",
   "title": "Proving a rewrite is the same system",
   "subtitle": "Parity discipline for a GPU runtime, and the day I voided over a thousand passing trials",
   "systems": [
    "activekv"
   ],
   "technologies": [
    "C++",
    "Python",
    "vLLM",
    "PyTorch XPU",
    "Bitwise comparison",
    "py-spy",
    "pybind11",
    "Numerical reproducibility"
   ],
   "stats": [
    {
     "value": "12 of 12",
     "label": "bitwise on both routes at the release"
    },
    {
     "value": "100+",
     "label": "lane notes voided and the count rebuilt from proofs"
    },
    {
     "value": "3",
     "label": "proofs before any lane may call a route native"
    }
   ],
   "lede": "A rewrite is finished when you can prove it behaves like the original. For a GPU serving runtime that means proving it on the real device, under concurrency, cancellation and shutdown, against a baseline that is not even bit-stable with itself in batched mode. Partway through the ActiveKV port I discovered that a long run of passing trials had been testing Python against Python, and the rule that came out of it now sits in the definition of done. The challenge Three distinct problems hide inside \"does the rewrite match\". The baseline is not deterministic: stock vLLM's batched output varies between its own runs, so a naive bitwise gate would fail the original against itself. A test can pass without",
   "quote": "A green suite is a claim about the thing it ran.",
   "evidence": [
    "Numerical reproducibility and bitwise validation: parity gated bitwise only where the reference agreed with itself across two runs, 12 of 12 bitwise on both routes at the release.",
    "Test design for native ports: differential suites rebuilt around the object types the server really passes, after stand-in suites passed on the CPU and failed at startup on the device.",
    "C++ and native ports with parity proof: a rule that a route counts as native only with 3 proofs, the binding site, every call-site condition and the run-log order.",
    "Engineering governance: 100+ lane notes voided and the count rebuilt from proofs after a bind-order defect showed the trials had tested Python against Python."
   ],
   "problem": "proof"
  },
  {
   "url": "https://coreyjames.ai/stories/context-beyond-vram/",
   "kind": "story",
   "title": "Context beyond VRAM",
   "subtitle": "Making a 27-billion-parameter model hold more conversation than its GPU can, exactly, on one card",
   "systems": [
    "activekv"
   ],
   "technologies": [
    "C++",
    "SYCL / oneAPI",
    "vLLM",
    "PyTorch XPU",
    "GPU memory management",
    "KV-cache engineering",
    "Intel Arc GPUs",
    "Numerical reproducibility"
   ],
   "stats": [
    {
     "value": "27B",
     "label": "parameters, a hybrid recurrent-attention model"
    },
    {
     "value": "32 GB",
     "label": "one Intel Arc Pro GPU, no second card"
    },
    {
     "value": "13 of 13",
     "label": "exact cells bit-identical to fully resident attention"
    }
   ],
   "lede": "A language model remembers a conversation through its key-value cache, and every serving engine I know keeps that whole cache on the GPU. For a long document, a codebase or an agent that has been working for hours, the cache grows with every token until it is the largest thing on the card after the weights. At that point the card's memory decides how much context the model can hold. I decided the history should leave the card and the request should keep running. ActiveKV is the result: a 27-billion-parameter model serving 128,000-token histories on one 32 GB Intel Arc Pro GPU, with an exact mode that is bit-identical to fully resident attention. The challenge The offload vLLM already had",
   "quote": "Memory saved is only valuable if you decide what to buy with it.",
   "evidence": [
    "KV-cache offload for LLM inference: pinned host memory as the authoritative copy of attention history and the GPU as a bounded working set, serving 128K-token histories for a 27B hybrid recurrent-attention model on one 32 GB card.",
    "Numerical reproducibility and bitwise validation: an exact tier accepted only when 13 of 13 cells matched fully resident attention bit for bit, each reference run twice and held to bitwise equality only where it agreed with itself.",
    "vLLM internals: an offload layer built into vLLM's scheduler, attention backend and memory accounting and delivered as a patch, serving histories from 32K to 128K tokens on one card, with correctness closed before speed work began.",
    "Intel GPU and SYCL/oneAPI engineering: a fence-safe staging pipeline in a native C++ runtime on an Intel Arc Pro GPU, each staging buffer released only after every copy and kernel that touched it had finished.",
    "Latency engineering under concurrency: inter-token latency at 31K-token prompts with four concurrent requests cut from 274 ms to 141 ms by spending 8 GB of reclaimed GPU memory.",
    "GPU inference optimisation: time to first token 12 to 22 percent below stock vLLM in every single-request cell, and a hybrid precision tier that cut 128K-token inter-token latency from 335 ms to 190 ms."
   ],
   "problem": "gpu-economics"
  },
  {
   "url": "https://coreyjames.ai/stories/judge-a-representation-by-the-bytes-it-stops-moving/",
   "kind": "story",
   "title": "Judge a representation by the bytes it stops moving",
   "subtitle": "Rewriting an acceptance gate that kept rejecting good compression, and what it bought at 128K tokens",
   "systems": [
    "activekv"
   ],
   "technologies": [
    "SYCL kernels",
    "Quantisation",
    "PCIe transfer modelling",
    "vLLM",
    "Intel Arc GPUs",
    "KV-cache engineering"
   ],
   "stats": [
    {
     "value": "0.7×",
     "label": "the per-tile speed rule I had set, withdrawn after a false rejection"
    },
    {
     "value": "12 of 12",
     "label": "bitwise cells for the hybrid route against its own reference"
    },
    {
     "value": "3 of 3",
     "label": "context sizes measured where the hybrid tier decoded faster"
    }
   ],
   "lede": "Once a model's history lives in host memory, every decode step is bound by how many bytes cross the bus, and the attention kernel's speed is a rounding error. My acceptance gate for compressed history formats did not know that. It measured kernel speed per tile and kept rejecting candidates that would have won. I rewrote the gate around end-to-end economics at the target context size: bytes saved per token against GPU time added. The challenge ActiveKV stages a context's attention history across PCIe on each step. At long contexts the copy dominates. A planning analysis for the exact tier put the transfer at many times the cost of the attention itself at 128K. A compressed format that halves the",
   "quote": "A format that loses at 8K and wins at 128K is a format for long contexts, and the gate should say so.",
   "evidence": [
    "KV-cache offload for LLM inference: an acceptance gate rewritten from per-tile kernel cost to whole-step economics, bytes saved per token against GPU time added.",
    "Performance modelling: a transfer model built from measured bus behaviour on the card, judging each candidate representation at its target context size.",
    "LLM quantization (INT8 KV cache): a compressed history tier that passed 12 of 12 bitwise cells against its own reference and decoded faster at 3 of 3 context sizes.",
    "Engineering judgment: withdrew my own 0.7x per-tile speed rule after it produced a false rejection at 128K tokens."
   ],
   "problem": "gpu-economics"
  },
  {
   "url": "https://coreyjames.ai/stories/the-observer-that-changed-the-answer/",
   "kind": "story",
   "title": "The observer that changed the answer",
   "subtitle": "Discovering that my own profiler caused the serialisation it reported, and retracting a verdict I had already acted on",
   "systems": [
    "activekv"
   ],
   "technologies": [
    "PyTorch XPU",
    "Level Zero",
    "GPU copy engines",
    "Instrumented performance methodology",
    "Intel Arc GPUs"
   ],
   "stats": [
    {
     "value": "≤ 0.21",
     "label": "copy and compute overlap with timing-enabled events on, from 0.02"
    },
    {
     "value": "≥ 0.79",
     "label": "overlap with no events, or with release-build events only, up to 1.09"
    },
    {
     "value": "3",
     "label": "variants interleaved in one process to test the instrument"
    }
   ],
   "lede": "A trace from my instrumented runtime showed that host-to-device copies were not overlapping with compute on the Intel card. I believed it, and I made a design decision on it. Then a controlled experiment showed that the timing events I had enabled to see the overlap were themselves the reason there was none. I retracted the verdict in the plan, and every overlap claim since gets an uninstrumented variant before anyone acts on it. The challenge Whether copies and compute overlap on a GPU decides the whole economics of a memory layer that stages data across the bus every step. You cannot see overlap without instrumentation, and instrumentation touches the thing it measures. The trace said the copy engine was",
   "quote": "Measure the measurement.",
   "evidence": [
    "GPU profiling and instrumentation: showed timing-enabled events serialised host-to-device copies behind compute, overlap 0.02-0.21 with them against 0.79-1.09 without.",
    "Performance experiment design: 3 instrumentation variants interleaved in one process, so the card, the driver and the host load were identical for all of them.",
    "Intel GPU and SYCL/oneAPI engineering: traced timing events to timestamp commands on the compute engine that made the copy engine wait, on the Level Zero runtime.",
    "Scientific integrity in engineering: a written retraction of my own verdict in the plan, and a standing rule that every overlap claim gets an uninstrumented control."
   ],
   "problem": "proof"
  },
  {
   "url": "https://coreyjames.ai/stories/bringing-a-serving-stack-up-on-new-silicon/",
   "kind": "story",
   "title": "Bringing a serving stack up on new silicon",
   "subtitle": "Patching Intel's Xe2 kernel stack where it had gaps, with outputs that stayed identical",
   "systems": [
    "activekv"
   ],
   "technologies": [
    "SYCL / DPC++",
    "oneDNN",
    "CUTLASS and CuTe",
    "Intel XPU kernels",
    "Intel Arc GPUs",
    "GPU kernel engineering"
   ],
   "stats": [
    {
     "value": "48",
     "label": "special-value combinations checked in one exact, flat rewrite"
    },
    {
     "value": "2",
     "label": "attention candidates rejected and kept as negatives"
    },
    {
     "value": "5",
     "label": "memory fences added for a synchronisation the original lacked"
    }
   ],
   "lede": "The Intel Arc Pro GPU is a new architecture, and the open kernel stacks that serve large models on it had gaps when I started: a GEMM path that chose the wrong tile for prefill, a recurrent-layer prefill with poor occupancy and a missing synchronisation, a missing attention statistic my memory layer needs, and run-to-run variance in some GEMM shapes. I patched the vendor's own sources inside the vendor's toolchain, with an identical-output gate on every change. Outputs stayed unchanged on the gated path. The challenge Serving on brand-new hardware means working above a kernel stack that is still catching up with the silicon. The vendor's libraries were open, which made patching possible, and a patch to a GEMM library",
   "quote": "Exactness is a property I want in the product.",
   "evidence": [
    "Intel GPU and SYCL/oneAPI engineering: patched the vendor's open kernel stacks on Intel Xe2 hardware to cut cold 32K-token prefill from 21.54 s to 17.23 s with identical outputs.",
    "GPU kernel development: a recurrent-layer prefill fix for occupancy, output split and a missing synchronisation, with 5 memory fences added.",
    "Numerical reproducibility and bitwise validation: an exact kernel rewrite checked across 48 special-value combinations, kept for exactness with no whole-workload gain.",
    "Performance engineering discipline: one change, one patch, one gate, with 2 attention candidates rejected and kept as documented negatives."
   ],
   "problem": "gpu-economics"
  },
  {
   "url": "https://coreyjames.ai/stories/a-message-broker-that-understands-tokens/",
   "kind": "story",
   "title": "A message broker that understands tokens",
   "subtitle": "Scheduling GPU inference by the shape of the work, so two different cards ran at a 99.9 percent cache hit rate with almost no padding",
   "systems": [
    "inference-fabric"
   ],
   "technologies": [
    "Rust",
    "Custom TCP wire protocols",
    "Memory-mapped storage",
    "Batch scheduling",
    "TensorRT-LLM",
    "Prometheus and Grafana",
    "NVIDIA Blackwell GPUs"
   ],
   "stats": [
    {
     "value": "0.421%",
     "label": "padding waste across one shared backlog"
    },
    {
     "value": "0",
     "label": "shape switches mid-stream"
    },
    {
     "value": "24,000",
     "label": "lines of Rust in four crates"
    }
   ],
   "lede": "A general-purpose queue moves bytes and knows nothing about what they cost to run. GPU inference cost depends almost entirely on the shape of the work: how long the prompts are, how much each prompt shares with its neighbours, how much padding a batch carries. I built a broker whose unit of scheduling is the token. It organises incoming work so that each batch is shape-pure, packs batches to each GPU's declared limits, and delivers them so the engine's cache keeps hitting. The challenge I had a backlog of billions of tokens to generate and two GPUs of different sizes to do it with. A conventional queue would hand each card whatever came next. The large card would waste capacity",
   "quote": "Four integers describe any consumer, including ones that do not exist yet.",
   "evidence": [
    "Token-aware scheduling: a Rust broker that batches GPU inference by prompt shape, with 0.421% padding waste across one shared backlog and 0 shape switches mid-stream.",
    "Message broker and queue design: a four-crate Rust broker of about 24,000 lines with a disk-backed, shape-pure backlog that survives restarts.",
    "Inference serving architecture: every consumer described by four numbers, so a 32 GB and a 16 GB NVIDIA Blackwell card drained one backlog at a 99.9 percent cache hit rate."
   ],
   "problem": "gpu-economics"
  },
  {
   "url": "https://coreyjames.ai/stories/millions-of-queued-items-that-were-not-there/",
   "kind": "story",
   "title": "Millions of queued items that were not there",
   "subtitle": "Fixing what 'done' meant in a GPU work broker until the token ledger balanced to zero",
   "systems": [
    "inference-fabric"
   ],
   "technologies": [
    "Rust",
    "Append-only logs",
    "Memory-mapped storage",
    "TCP protocol design",
    "Distributed-systems accounting",
    "Prometheus and Grafana"
   ],
   "stats": [
    {
     "value": "6.5 M",
     "label": "items that had ceased to exist between handoff and GPU"
    },
    {
     "value": "12.3 B",
     "label": "tokens received afterwards, and the same routed"
    },
    {
     "value": "2",
     "label": "failures with one root: loss under load, duplicates after a restart"
    }
   ],
   "lede": "The broker's registry and its storage disagreed by millions of items. Somewhere between a producer handing work in and a GPU finishing it, that work had ceased to exist without a trace. I traced it to a definition: the broker counted an item as consumed the moment it was read, and dropped it if the consumer's channel happened to be full. I redefined \"done\" as acknowledged on completion, and rebuilt the accounting around that until received and routed agreed to the token. The challenge Two problems with one root. Work disappeared under load and nothing reported it: the registry believed the items were pending, the storage no longer had them, and the GPUs had never seen them. And when the",
   "quote": "The alternative was a system that was fast and occasionally lost millions of items.",
   "evidence": [
    "Exactly-once delivery and crash recovery: done redefined as delivered and acknowledged in a GPU work broker, so a full channel delays work and a restart leaves work held by GPU workers alone.",
    "Distributed systems correctness: 6.5 M items that had ceased to exist between handoff and GPU traced to one root, the broker's definition of done.",
    "Observability and alerting: accounting panels that show tokens received and routed side by side, 12.3 B of each afterwards with a difference of zero."
   ],
   "problem": "data-paths"
  },
  {
   "url": "https://coreyjames.ai/stories/from-44k-to-163k-tokens-per-second/",
   "kind": "story",
   "title": "From 44K to 163K tokens per second",
   "subtitle": "Raising one 7-billion-parameter model's throughput on consumer GPUs, one measured layer at a time",
   "systems": [
    "inference-fabric"
   ],
   "technologies": [
    "TensorRT-LLM",
    "FP8 inference",
    "CUDA",
    "Nsight Systems",
    "Prometheus and Grafana",
    "Rust",
    "C++",
    "Batch scheduling",
    "NVIDIA Blackwell GPUs"
   ],
   "stats": [
    {
     "value": "44K",
     "label": "tokens per second from the clean engine sweep, the baseline"
    },
    {
     "value": "4.95 M",
     "label": "tasks in a ten-hour run on one GPU, zero retries"
    },
    {
     "value": "96.9%",
     "label": "streaming-multiprocessor use of the larger card in the two-card window"
    },
    {
     "value": "3",
     "label": "plausible ideas measured and dropped"
    }
   ],
   "lede": "Stock TensorRT-LLM, set up the obvious way, left most of a consumer GPU idle on bulk generation. I was building a pipeline that would generate and mine tens of millions of items, so idle capacity was the whole cost. I took one model, a 7-billion-parameter dense model in FP8, from about 44,000 tokens per second on a single NVIDIA Blackwell GPU to a five-minute mean of 163,000 across two NVIDIA Blackwell GPUs, with no custom model kernels. Each step was a change to one layer of the serving stack, measured before and after, and the changes that made things slower are on this page next to the ones that worked. The challenge The ceiling was never the engine. It was",
   "quote": "A throughput figure without its window and hardware is a rumour.",
   "evidence": [
    "GPU inference optimisation: a 7B dense model in FP8 taken from about 44,000 tokens per second on one NVIDIA Blackwell GPU to a five-minute mean of 163,000 across two, with no custom model kernels.",
    "TensorRT and TensorRT-LLM engineering: an engine tier sweep that found the token budget per step to be the largest engine-side lever, with a tuned single card at 90K tokens per second on stock kernels.",
    "Token-aware scheduling: a shape-aware broker with cache-coherent dispatch feeding a second Blackwell GPU on the same queue, the larger card at 96.9% streaming-multiprocessor use in the two-card window.",
    "High-throughput batch inference: producers decoupled from the engine so a slow producer can never starve the GPU, and 4.95 M tasks in a ten-hour run on one GPU with zero retries.",
    "Performance benchmarking methodology: one layer changed at a time against the clean engine sweep, not a stalled early run, with host-memory KV cache (6.8% slower) and custom CUDA graphs (under 1%) measured and dropped.",
    "LLM quantization: FP8 weights kept on stock kernels after INT4 weights measured slower than FP8 on this hardware."
   ],
   "problem": "gpu-economics"
  },
  {
   "url": "https://coreyjames.ai/stories/tools-that-build-tools-under-governance/",
   "kind": "story",
   "title": "Tools that build tools, under governance",
   "subtitle": "A generator that lets agents add new capabilities to the estate, inside a sandbox, callable only after a human restart",
   "systems": [
    "fafo-core"
   ],
   "technologies": [
    "Rust",
    "Code generation",
    "Handlebars templates",
    "Model Context Protocol (MCP)",
    "Link-time registration",
    "PostgreSQL",
    "YAML schema compilation"
   ],
   "stats": [
    {
     "value": "7 of 14",
     "label": "function crates in the estate carry the generator's fingerprints"
    },
    {
     "value": "14 files",
     "label": "per function: eight framework, six sandboxed"
    },
    {
     "value": "4",
     "label": "places written in one rollback-protected transaction per generation"
    }
   ],
   "lede": "My agents could call tools and could not add one. Every new capability meant a human wiring a crate into the gateway, the orchestrator and the result path by hand. I built a generator, exposed as a tool, that lets an agent author a new function for the estate. The generated code runs in a sandbox that sees only a capability-bounded context, cannot open its own connections or write the database directly, and runs only after a human rebuilds and restarts the gateway. The challenge AI-written processing code, given a database handle, will build unsafe queries, write tables it should not, and open connections nobody audits. And a tool that is half-registered, present in the gateway and absent from the",
   "quote": "Self-extending systems are where safety usually goes to die.",
   "evidence": [
    "Tool synthesis and governed API integration: a generator, itself an MCP tool, that lets an AI agent author a new function, with 7 of 14 function crates in the estate carrying its fingerprints.",
    "Sandboxing generated code: 14 files per function, eight framework files locked and six in a sandbox that reads through a schema resolver and writes only through the governed queue.",
    "Transactional code generation: 4 places written in one rollback-protected transaction per generation, with a symmetric delete and link-time registration so nothing is half-registered.",
    "Human-in-the-loop control for AI agents: a generated function runs only after a human rebuilds and restarts the gateway.",
    "Self-audit and redesign: a first version that passed its own fifteen-point check but generated code that did not compile, rebuilt with inverted ownership instead of patched."
   ],
   "problem": "governed-agents"
  },
  {
   "url": "https://coreyjames.ai/stories/196-deadlocks-to-zero/",
   "kind": "story",
   "title": "196 deadlocks to zero",
   "subtitle": "Measuring a write path from the database itself, and finding that one index was the whole problem",
   "systems": [
    "fafo-core"
   ],
   "technologies": [
    "PostgreSQL",
    "Redis Streams",
    "Python benchmark tooling",
    "Rust",
    "Performance diagnosis"
   ],
   "stats": [
    {
     "value": "196 → 0",
     "label": "deadlocks during the run, before and after one index"
    },
    {
     "value": "1.25 M",
     "label": "rows committed in 185 seconds after the fix"
    },
    {
     "value": "16,370",
     "label": "peak rows committed a second; 6,752 on average"
    }
   ],
   "lede": "A bulk update workload through my shared write path had slowed to a crawl, with deadlocks every few seconds. The queue in front of the database reported healthy throughput, which was the first clue that the queue was the wrong instrument. I built a harness that measured from the only place that knows how many rows were committed, the database itself, and compared runs before and after a single schema change. The challenge The write path is shared by every producer in the estate, so a slow write path slows everything. The obvious metrics were the queue's own counters, and they measure intake: how much work was taken in, and nothing about how much landed. A diagnosis built on intake",
   "quote": "Only the database knows how many rows were committed.",
   "evidence": [
    "PostgreSQL performance tuning: a unique index on the update key took deadlocks during a bulk update from 196 to 0 on a write path shared by every producer.",
    "Performance benchmarking methodology: a harness that samples system load, queue depth and PostgreSQL tuple deltas and compares runs before and after one change, measuring committed rows, not intake.",
    "Write-path throughput: 1.25 M rows committed in 185 seconds after the fix, 16,370 a second at peak and 6,752 on average.",
    "Latency diagnosis: batch latency from 100 to 2,000 ms before the index and 7 to 37 ms after it."
   ],
   "problem": "data-paths"
  },
  {
   "url": "https://coreyjames.ai/stories/the-workload-that-shaped-the-platform/",
   "kind": "story",
   "title": "The workload that shaped the platform",
   "subtitle": "Generating tens of millions of traceable dataset items on two consumer GPUs, and letting that job decide what the substrate needed",
   "systems": [
    "fafo-core",
    "inference-fabric"
   ],
   "technologies": [
    "Rust",
    "PostgreSQL",
    "Redis",
    "TensorRT-LLM",
    "Grafana",
    "Data pipeline engineering",
    "NVIDIA Blackwell GPUs"
   ],
   "stats": [
    {
     "value": "876K",
     "label": "probes submitted in one captured window"
    },
    {
     "value": "131 M",
     "label": "tokens pending in the same window, with zero retries"
    },
    {
     "value": "156/s",
     "label": "probes per second through that window"
    }
   ],
   "lede": "My distillation research needed tens of millions of model-generated dataset items, each traceable back to the knowledge it was drawn from, produced fast enough to keep two GPUs saturated. design <blockquote class=\"dv-quote\" <p I did not design a platform and then look for a workload. I ran the workload and built exactly what it forced.</p </blockquote The challenge Dataset construction at this scale is an industrial data pipeline. Every item needs a persistent identity so a crash does not lose it or run it twice. Writes span several tables and must stay referentially consistent. Prompts have to be shaped so the inference engine can reuse cached work across millions of near-identical requests. And none of it may wait on anything",
   "quote": "I did not design a platform and then look for a workload. I ran the workload and built exactly what it forced.",
   "evidence": [
    "High-throughput batch inference: a dataset pipeline that kept two consumer GPUs saturated, with 876K probes submitted in one captured window at 156/s.",
    "Token-aware scheduling: shape-similar batches with minimal padding, 131 M tokens pending in the same window with zero retries.",
    "Exactly-once delivery and crash recovery: lease-based claiming, multi-table atomic writes and recovery of buffered items after a broker loss, so work was neither lost nor run twice.",
    "Data pipeline engineering with provenance: tens of millions of model-generated dataset items, each traceable to the knowledge it was drawn from.",
    "Platform design from workloads: each wall the pipeline hit added the one capability it forced, including a decoupled submit-and-exit producer with a separate completion service."
   ],
   "problem": "gpu-economics"
  },
  {
   "url": "https://coreyjames.ai/stories/the-hardening-fix-that-locked-everyone-out/",
   "kind": "story",
   "title": "The hardening fix that locked everyone out",
   "subtitle": "Reversing my own security change within a day, because the threat model said a different control was the one that mattered",
   "systems": [
    "auth-and-access-plane"
   ],
   "technologies": [
    "OAuth 2.0",
    "Dynamic client registration (RFC 7591)",
    "PKCE",
    "Python",
    "Redis",
    "NGINX",
    "Application security hardening"
   ],
   "stats": [
    {
     "value": "3",
     "label": "holes the review found; the worst, anonymous registration with attacker-chosen redirects"
    },
    {
     "value": "7",
     "label": "acceptance probes, one or more for each fix"
    },
    {
     "value": "24 h",
     "label": "from adding the registration lock to reverting it"
    }
   ],
   "lede": "A security review of my deliberately public OAuth endpoint found holes, the worst of them in client registration. I fixed all three, checked the fixes with explicit probes, and the next morning every AI assistant that used the endpoint could no longer authenticate. I re-ran the threat model. The registration lock had added friction without adding security, because the control that protects is the consent screen, where I log in and approve every grant. I reverted my own fix and wrote down why. The challenge The endpoint exists so that AI assistants, including commercial ones, can connect to my private tool estate. It has to be public, and the assistants self-register as OAuth clients, some of them caching their client",
   "quote": "The consent screen is the control. Registration is bookkeeping.",
   "evidence": [
    "Security incident judgment: I reverted my own registration lock within 24 h of adding it, after it locked every AI assistant out and the threat model showed consent was the control.",
    "OAuth 2.0 and identity architecture: a deliberately public endpoint where AI assistants self-register as clients and a person approves every grant on the consent screen.",
    "Security review triage: 3 findings fixed in severity order with minimal changes, each fix checked by acceptance probes, 7 in all.",
    "Threat modelling for AI client access: a hostile registration shown to gain nothing unless a person approves that client on the consent screen."
   ],
   "problem": "governed-agents"
  },
  {
   "url": "https://coreyjames.ai/stories/directing-ai-coding-agents-at-program-scale/",
   "kind": "story",
   "title": "Directing AI coding agents at program scale",
   "subtitle": "How I run engineering programs with teams of frontier and open-source models, and why evidence, not the agents, decides",
   "systems": [
    "agentos",
    "activekv",
    "agent-swarm",
    "fafo-core",
    "capabilities-model",
    "fafohive"
   ],
   "technologies": [
    "Governed AI-assisted software engineering",
    "Frontier coding models",
    "Open-source models",
    "git",
    "Separation-of-duties review design"
   ],
   "stats": [
    {
     "value": "3",
     "label": "weeks at most for a native port, bit-identical in every parity cell"
    },
    {
     "value": "24",
     "label": "performance promotions in four days, each through an intake review"
    },
    {
     "value": "23 of 23",
     "label": "close items closed under independent review"
    }
   ],
   "lede": "Most of the code behind the systems on this site was written by AI coding agents. The interesting part is that the programs finished, passed independent review, and can be trusted: a native port with bit-identical output, an API platform closed under independent review, a fine-tuned model with a frozen evaluation. That happens because I run agent teams the way an architect runs an engineering organisation. I write the rules, I separate the builders from the judges, and I let evidence decide. The challenge AI coding agents are fast, tireless and confidently wrong. Left to themselves they over-claim completion, drift from the plan as context fills, and optimise for whatever metric is in front of them, including gaming a benchmark",
   "quote": "The tests were real, and they were testing the wrong thing.",
   "evidence": [
    "Technical leadership of agent teams: engineering programs run with teams of frontier and open-source models under written rules, with builders and judges on different model families.",
    "C++ and native ports with parity proof: a native port completed in at most 3 weeks, bit-identical in every parity cell.",
    "Performance engineering governance: 24 performance promotions in four days, each through an intake review that rejects fixture-tuned gains.",
    "Evidence-gated acceptance: an API platform held open against the agents' own done and closed on 23 of 23 close items under independent review.",
    "Integrity of results: over a thousand passing trials voided when a native component was found registered after the code path was chosen, and the work redone with proof of binding order."
   ],
   "problem": "governed-agents"
  },
  {
   "url": "https://coreyjames.ai/stories/a-27b-model-on-one-32gb-intel-card/",
   "kind": "story",
   "title": "A 27B model on one 32 GB Intel card",
   "subtitle": "A measured, attributed and published 4-bit quantization of a 27-billion-parameter hybrid recurrent-attention open-weight model for an Intel Arc Pro GPU",
   "systems": [
    "capabilities-model",
    "activekv"
   ],
   "technologies": [
    "Weight quantisation (W4A16)",
    "compressed-tensors",
    "Intel XPU vLLM",
    "PyTorch XPU",
    "Intel Arc GPUs",
    "Hugging Face Hub",
    "Hybrid recurrent-attention 27B-class models"
   ],
   "stats": [
    {
     "value": "+36%",
     "label": "sustained output throughput over the mixed 4-bit and 8-bit control, 64 clients"
    },
    {
     "value": "3.33%",
     "label": "higher perplexity than full precision on an 8-document diagnostic set"
    },
    {
     "value": "1,798",
     "label": "tokens per second total at 32 clients, 1,536-token prompts, prefix caching on"
    }
   ],
   "lede": "The base model, a 27-billion-parameter hybrid recurrent-attention open-weight model, does not fit in BF16 on a 32 GB Intel Arc Pro GPU, and I needed it to, with room left for context and concurrency. I built a 4-bit-weight quantization that fits it, ran a four-arm experiment to attribute exactly where the speed came from, and published the model with its card on Hugging Face. The model card states the trade-off in plain numbers. The challenge Fitting a large model on a smaller card is routine on NVIDIA hardware with mature tooling. On a new Intel architecture, with a stock XPU build of vLLM and no forked kernels, it was not. And a quantization you intend to publish has to be",
   "quote": "I took the throughput and stated the cost.",
   "evidence": [
    "LLM quantization (4-bit): a weight-only W4A16 recipe for a 27-billion-parameter hybrid model, rounded from hash-checked weights with no calibration data, at 3.33% higher perplexity than full precision.",
    "Intel GPU inference: a 27B model fitted on one 32 GB Intel Arc Pro GPU under the unmodified Intel XPU build of vLLM, 1,798 tokens per second in total at 32 clients.",
    "Experimental design for performance attribution: a four-arm experiment crossed over across two cards, attributing a +36% sustained throughput gain at 64 clients to what changed between arms.",
    "Model publication and provenance: a model published on Hugging Face with per-module manifests, hash-replayed measurements and release validation of 433 files per checkpoint."
   ],
   "problem": "gpu-economics"
  },
  {
   "url": "https://coreyjames.ai/stories/spend-structure-before-spending-waste/",
   "kind": "story",
   "title": "Spend structure before spending waste",
   "subtitle": "The lane-packing algorithms that let a GPU broker pad 0.4 percent and keep two different cards at a 99.9 percent cache hit rate",
   "systems": [
    "inference-fabric"
   ],
   "technologies": [
    "Rust",
    "Token-aware GPU batch scheduling",
    "Append-only log and journal design",
    "Memory-mapped storage",
    "TensorRT-LLM",
    "NVIDIA Blackwell GPUs"
   ],
   "stats": [
    {
     "value": "2,048",
     "label": "rolling lanes per prompt shape"
    },
    {
     "value": "17,800/s",
     "label": "lane reuses, against 0.49 new lanes per second"
    },
    {
     "value": "99.9%",
     "label": "key-value cache hit rate on both cards"
    },
    {
     "value": "12.3 B",
     "label": "tokens received and the same routed, difference zero"
    }
   ],
   "lede": "Padding is the tax a GPU pays for batching sequences of different lengths, and cache misses are the tax it pays for mixing prompts that share nothing. A queue that moves bytes knows about neither. I built the broker in my inference pipeline to know about both, with a set of algorithms that decide, for every item, which batch it belongs in and when it goes. The problem Two prompts can share a batch cheaply only if they share cacheable structure, the system prompt, the few-shot block, the tool schema, and have similar lengths. Length is cheap to read. Shared structure is not, and the broker must never parse prompts or know the model. Fixed power-of-two length buckets waste up",
   "quote": "A poisoned cache is worse than a restart.",
   "evidence": [
    "Token-aware scheduling: shape signatures from ordered prefix hashes and 2,048 rolling lanes per shape, keeping two cards at a 99.9% key-value cache hit rate.",
    "Batch padding optimisation: a waste threshold that rises from one percent to ten percent with lane pressure, with a 16-token floor and a 128-token cap, for 0.421% padding.",
    "Message broker and queue design: lane reuse at 17,800/s against 0.49 new lanes per second, and 12.3 B tokens received and routed with a difference of zero.",
    "Distributed systems correctness: a dispatch loop that yields after 100 milliseconds, after a fill of 3,099 batches blocked heartbeats long enough for healthy GPUs to be declared dead."
   ],
   "problem": "gpu-economics"
  },
  {
   "url": "https://coreyjames.ai/stories/thirty-eight-metrics-in-a-dozen-passes/",
   "kind": "story",
   "title": "Thirty-eight metrics in a dozen passes",
   "subtitle": "A hand-written CUDA engine for Blackwell that scores thousands of embedding clusters at once and searches them with the same kernels",
   "systems": [
    "inference-fabric"
   ],
   "technologies": [
    "CUDA C++",
    "CUDA Driver API",
    "GPU numerical kernel design",
    "Approximate nearest-neighbour search",
    "Rust",
    "NVIDIA Blackwell GPUs",
    "Determinism and numerical reproducibility"
   ],
   "stats": [
    {
     "value": "11×",
     "label": "faster centroid family at 100,000 members after the rewrite"
    },
    {
     "value": "500K/s",
     "label": "members through two-means, no atomics"
    },
    {
     "value": "0.85",
     "label": "minimum recall at ten against exact search, held in CI"
    },
    {
     "value": "11,600",
     "label": "lines of Rust around about 11,000 of CUDA"
    }
   ],
   "lede": "My distillation research produces millions of embeddings grouped into clusters, and it needs to know, for every cluster, how tight it is, whether it has sub-structure, how it relates to its neighbours, and how much information it carries. That is thirty-eight statistics per cluster, over vectors of 1,024 dimensions, for thousands of clusters at a time. I wrote a CUDA engine for it, from Rust against the driver API, compiled natively for Blackwell, with a CPU reference and equivalence tests for every kernel. The same engine does exact, inverted-file and lattice vector search, and a fused variant computes cluster health as a side effect of the search it was already doing. The shape of the engine Every metric kernel takes",
   "quote": "The quadratic distance matrix never exists.",
   "evidence": [
    "CUDA kernel development: a hand-written CUDA engine for NVIDIA Blackwell scoring thirty-eight statistics per cluster over 1,024-dimension vectors, with no sampling and no caps.",
    "Embedding analytics and cluster metrics: the centroid family made 11x faster at 100,000 members, and two-means at about 500K/s members with no atomics.",
    "Vector search and ANN indexes: exact, inverted-file and lattice search on the same kernels, with recall at ten held at 0.85 or better against exact search in CI.",
    "Rust systems engineering: 11,600 lines of Rust around about 11,000 of CUDA, reaching the CUDA 13 driver API through a 300-line safe wrapper."
   ],
   "problem": "embedding-analytics"
  },
  {
   "url": "https://coreyjames.ai/stories/constraint-made-cheaper-than-no-constraint/",
   "kind": "story",
   "title": "Constraint made cheaper than no constraint",
   "subtitle": "A grammar-bounded CUDA decoder in which enforcing the tool catalog costs less than not enforcing it",
   "systems": [
    "capabilities-model"
   ],
   "technologies": [
    "CUDA C++",
    "Grammar-constrained decoding",
    "GPU inference engine engineering",
    "Rust",
    "NVIDIA Blackwell GPUs",
    "Determinism and numerical reproducibility"
   ],
   "stats": [
    {
     "value": "172 µs",
     "label": "less per token with the catalog enforced than with no constraint at all"
    },
    {
     "value": "607",
     "label": "trie nodes for 42 tools, held in 64 KiB of constant memory"
    },
    {
     "value": "12 of 12",
     "label": "bit-identity gates; identical top results across 2,345 shuffled batches"
    }
   ],
   "lede": "Constrained decoding is usually a tax. A serving framework computes every logit, then masks the ones the grammar forbids, then samples. My tool-discovery decoder turns that around. The grammar knows, before a token's forward pass finishes, that the answer is one of the current node's outgoing edges, so the output layer only computes those. Around that idea is a decoder I built from the ground up in CUDA: a trie in constant memory, a device-resident decode loop, a batched engine with paged memory, and determinism by construction. The grammar as a trie over tokens The tool registry is compiled into a trie over the model's own token ids, stored as compressed sparse rows: an edge range per node, a token",
   "quote": "Nothing is kept until it moves the 469-query wall clock.",
   "evidence": [
    "Grammar-constrained decoding: a CUDA decoder whose output layer computes only the edges the trie permits, 172 µs less per token with the catalog enforced than with no constraint.",
    "CUDA kernel development: a token trie of 607 nodes for 42 tools held in 64 KiB of constant memory, with masked sampling in one block of 256 threads.",
    "Deterministic GPU computation: 12 of 12 bit-identity gates and identical top results across 2,345 shuffled batches.",
    "Fail-loud inference design: a decoder that stops with an error when the mask leaves nothing, so a broken grammar never produces a plausible answer."
   ],
   "problem": "small-models"
  },
  {
   "url": "https://coreyjames.ai/stories/half-the-bytes-exactly-merged/",
   "kind": "story",
   "title": "Half the bytes, exactly merged",
   "subtitle": "The INT8 history format and the SYCL attention kernels that halve ActiveKV's bus traffic, and the log-sum-exp merge that keeps the result exact",
   "systems": [
    "activekv"
   ],
   "technologies": [
    "SYCL",
    "KV-cache engineering",
    "Model quantization",
    "GPU numerical kernel design",
    "Intel Arc GPUs",
    "Numerical reproducibility"
   ],
   "stats": [
    {
     "value": "0.00267",
     "label": "worst merged own-format error of the selected format"
    },
    {
     "value": "12 of 12",
     "label": "bitwise cells the hybrid route passes against its own reference"
    },
    {
     "value": "26%",
     "label": "faster decode of one query row over a 32-page compressed tile than BF16"
    },
    {
     "value": "31%",
     "label": "faster again when one launch serves two requests"
    }
   ],
   "lede": "Once a model's attention history lives in host memory, decode speed is bus arithmetic. The model ActiveKV serves carries 64 KiB of key-value history per token across its sixteen dense layers, and the exact path re-reads all of it for every generated token: 2.1 GB at 32K tokens, 8.4 GB at 128K, across a copy engine that moves about 26 GB per second. A calibrated model of that arithmetic matched measured latency within a few percent at every context length. So the way to make long contexts faster was to move fewer bytes without changing the answer. That took a compressed history format, attention kernels that read it directly, and a merge that combines compressed and exact attention with no",
   "quote": "Averaging those outputs would be wrong, because each is normalised by a different denominator.",
   "evidence": [
    "LLM quantization (INT8 KV cache): a compressed history format with eight-bit codes and separable key scales, worst merged own-format error 0.00267 against a 0.005 gate.",
    "SYCL kernel development on Intel Xe2: integer query-key attention on the matrix units, from 18.69 to 8.74 ms per prefill tile, nine percent faster than BF16.",
    "Exact attention merging: partial attention across tiles and precisions combined through log-sum-exp weights with no approximation, 12 of 12 bitwise cells on the hybrid route.",
    "KV-cache offload for LLM inference: per-token latency at 128K tokens cut from 335.2 ms on the exact tier to 190.0 ms on the hybrid tier.",
    "GPU inference optimisation: one decode launch serving two requests 31% faster than two single calls, and one-row compressed decode 26% faster than BF16."
   ],
   "problem": "gpu-economics"
  },
  {
   "url": "https://coreyjames.ai/stories/staging-without-a-stall/",
   "kind": "story",
   "title": "Staging without a stall",
   "subtitle": "The fence-safe lifecycle and the admission arithmetic that let ActiveKV stream history across the bus without ever reading a stale buffer",
   "systems": [
    "activekv"
   ],
   "technologies": [
    "C++",
    "GPU memory management",
    "KV-cache engineering",
    "PyTorch XPU",
    "Intel Arc GPUs"
   ],
   "stats": [
    {
     "value": "12 of 12",
     "label": "bitwise cells on both routes, staged against fully resident attention"
    },
    {
     "value": "14.5",
     "label": "tokens per second, up from 8.4, four 31,744-token requests"
    },
    {
     "value": "33.2 GB",
     "label": "device peak on the same run, up from 24.8: freed memory put to work"
    }
   ],
   "lede": "Each dense layer in ActiveKV needs its history on the device for one attention call. The copy in is asynchronous, the attention is asynchronous, and the new token's keys and values must flow back to the host copy. A staging buffer reused one event too early reads another layer's or another step's history, and the attention output looks plausible. Nothing crashes. I designed the staging lifecycle so that this class of bug cannot happen, and the admission arithmetic so that the card refuses what it cannot serve instead of degrading. Two copy queues and device-side ordering The engine owns a dedicated host-to-device queue, a dedicated device-to-host queue, and the attention compute queue. Ordering between them is on the device: the",
   "quote": "Nothing is recycled on an uncertain fence.",
   "evidence": [
    "Asynchronous GPU memory management: a fence-safe staging lifecycle keyed by leases, in which nothing is recycled on an uncertain fence.",
    "Numerical reproducibility and bitwise validation: whole-layer staging accepted only on bit-identical logits against fully resident attention, 12 of 12 on both routes.",
    "GPU memory admission control: explicit page pools with targets, bursts and least-recently-active reclamation that refuses a request rather than degrading it.",
    "Latency engineering under concurrency: four 31,744-token requests on the quiet benchmark machine went from 350 to 267 ms inter-token latency and 8.4 to 14.5 tokens per second.",
    "GPU memory reuse: device peak raised from 24.8 to 33.2 GB to spend memory freed by host-resident history on decode speed."
   ],
   "problem": "gpu-economics"
  },
  {
   "url": "https://coreyjames.ai/stories/redistribution-inside-the-database/",
   "kind": "story",
   "title": "Redistribution inside the database",
   "subtitle": "The lattice functions that grow, protect and score concept clusters over millions of vectors without leaving PostgreSQL",
   "systems": [
    "fafo-core",
    "capabilities-model"
   ],
   "technologies": [
    "PostgreSQL",
    "pgvector",
    "SQL",
    "Rust",
    "Hybrid retrieval"
   ],
   "stats": [
    {
     "value": "1,024",
     "label": "dimensions in every unit's embedding"
    },
    {
     "value": "8",
     "label": "signals weighted into each cluster's pressure"
    },
    {
     "value": "~11,000",
     "label": "lines of Rust in the sole acceptance authority for new clusters"
    }
   ],
   "lede": "My distillation corpus is a lattice: question-and-answer units, each with a 1,024-dimension embedding, grouped into concept clusters with a centroid, a tier and a pressure score. The lattice has to grow where it is thin, stay stable where it is dense, admit new clusters only on evidence, and never let its seed units move. I built those behaviours as functions that run inside PostgreSQL, because the work is a set of index-backed nearest-neighbour queries and one atomic update, and moving millions of vectors to an application server would cost more than the work itself. Pressure Every cluster carries a saturation pressure between zero and one, higher meaning more need to grow. It is a weighted sum of signals about the",
   "quote": "Fill once, protect seeds, keep history, and the lattice converges instead of churning.",
   "evidence": [
    "In-database computation with PostgreSQL and pgvector: lattice functions that grow, protect and score concept clusters over millions of vectors of 1,024 dimensions without leaving the database.",
    "Vector search and ANN indexes: lateral nearest-neighbour queries through an inverted-file index, so each centroid search uses the index instead of a cross product.",
    "Transactional data redistribution: one function runs a whole schema as a single transaction, moves units in one update, and logs fills and drains with counts and a run id.",
    "Deterministic acceptance scoring: ~11,000 lines of Rust as the sole acceptance authority for new clusters, every failed test returned as a reason.",
    "Tunable data-quality models: cluster pressure from 8 weighted signals, four protection rules counted separately, and three presets from conservative to aggressive."
   ],
   "problem": "data-paths"
  },
  {
   "url": "https://coreyjames.ai/stories/a-detector-for-a-silent-corruption/",
   "kind": "story",
   "title": "A detector for a silent corruption",
   "subtitle": "How the hidden-state extraction backend proves which token it is reading before it writes tens of millions of rows",
   "systems": [
    "inference-fabric"
   ],
   "technologies": [
    "NVIDIA TensorRT",
    "C++",
    "Hidden-state extraction",
    "Dense 7B-class models",
    "NVIDIA Blackwell GPUs"
   ],
   "stats": [
    {
     "value": "2",
     "label": "plausible gather conventions, and the engine accepts either"
    },
    {
     "value": "0.1%",
     "label": "checksum change that proves the engine reads the input"
    },
    {
     "value": "25,800",
     "label": "tokens per second over 10.8 million tokens of extraction"
    }
   ],
   "lede": "The extraction mode of my inference runtime reads a model's internal representation, the input to its language-model head, for every probe, in one forward pass with no generation, at very large batch. The engine's packed-sequence interface takes an input that tells the attention plugin which token's state to gather for each sequence. Two conventions are plausible: the cumulative length, or the cumulative length minus one. The documentation did not settle which this engine expected. A wrong guess still produces well-formed vectors, just the wrong token's, or the next sequence's first token, for every probe. The result would be a silently corrupt dataset of tens of millions of rows. So the backend proves the convention before it extracts anything. The extraction",
   "quote": "The test runs once per engine load, and it is the difference between a dataset and a disaster.",
   "evidence": [
    "TensorRT and TensorRT-LLM engineering: a raw TensorRT hidden-state extraction backend at 25,800 tokens per second over 10.8 million tokens of extraction.",
    "Numerical verification of inference engines: a warm-up detector that tries both of 2 plausible gather conventions and needs a 0.1% checksum change to prove the engine reads its input.",
    "Data provenance for ML pipelines: each hidden state written as a self-describing payload with magic, dtype, shape and hash, appended with a lineage-checked catalog row."
   ],
   "problem": "proof"
  },
  {
   "url": "https://coreyjames.ai/stories/what-the-work-cost/",
   "kind": "story",
   "title": "What the work cost, to the penny",
   "subtitle": "One real engineering program, attributed to the penny, and a cache discipline that returned four-fifths of the bill",
   "systems": [
    "agentos",
    "fafohive"
   ],
   "technologies": [
    "Cost attribution for AI work",
    "PostgreSQL",
    "Budget enforcement and cost governance",
    "Context engineering and persistent agent memory"
   ],
   "stats": [
    {
     "value": "11,193",
     "label": "priced model calls, each tied to its task"
    },
    {
     "value": "3.197 B",
     "label": "tokens attributed across the arc"
    },
    {
     "value": "94.5%",
     "label": "overall cache hit rate"
    },
    {
     "value": "36,515",
     "label": "governed state transitions along the way"
    }
   ],
   "lede": "Most platforms report a vendor invoice. I wanted to know what the work cost: every model call priced, tied to the task that made it, rolled up by phase and by model, with the cache's contribution counted. I have that answer for one real delivery arc under my governance platform, down to about five and a half cents per governed step. Why cost is a field In AgentOS every model call is metered against the work order and task that made it, so cost attaches to the work rather than to a month. Budgets are part of the contract: a work order carries a spend ceiling, and exhausting it stops the work. Cheap is the default and expensive is a",
   "quote": "A model that remembers beats a model that recalls, and it costs less too.",
   "evidence": [
    "Cost attribution for AI work: 11,193 priced model calls tied to the tasks that made them, 3.197 B tokens attributed across one delivery arc, about five and a half cents per governed step.",
    "LLM cost optimisation with prompt caching: a 94.5% overall cache hit rate from stable rendered prefixes and reused grounding, returning four-fifths of the bill.",
    "Budget enforcement for AI agents: a spend ceiling on every work order that stops the work when exhausted, with model and reasoning effort named per role as data.",
    "Code intelligence economics: asking the code graph cost about 5,100 tokens per code question against 29,100 for manual exploration, across 536 recorded searches.",
    "Memory for AI agents: 289,304 stored observations recalled 452,834 times instead of being rediscovered, along 36,515 governed state transitions."
   ],
   "problem": "governed-agents"
  },
  {
   "url": "https://coreyjames.ai/stories/two-thousand-concurrent-workers/",
   "kind": "story",
   "title": "Two thousand concurrent workers",
   "subtitle": "Load-testing the memory and code-intelligence service with a fleet of AI agents on one workstation, with zero failures",
   "systems": [
    "fafohive"
   ],
   "technologies": [
    "Capacity engineering, backpressure and load testing",
    "Rust",
    "PostgreSQL",
    "Hybrid retrieval",
    "Code graph and static dependency analysis"
   ],
   "stats": [
    {
     "value": "2,000",
     "label": "concurrent AI workers on the retrieval tools at once"
    },
    {
     "value": "0",
     "label": "failures across the run"
    },
    {
     "value": "1,479",
     "label": "requests a second held in keyword mode, from a floor of 1,271"
    }
   ],
   "lede": "Every agent in my estate asks the memory service before it acts: what did we decide, what calls this symbol, how does this path work. If that service stalls under a fleet, every agent stalls with it. So I load-tested it the way the fleet uses it: two thousand concurrent AI workers hammering the retrieval tools at once, on a single workstation. Nothing failed. The fixture One workstation: a 24-core Intel Core Ultra with 256 GB of DDR5 and a consumer Blackwell GPU that was not used to accelerate retrieval. The service is Rust over PostgreSQL. design <figure class=\"dv-figure\" aria-label=\"How the two thousand workers were spread across the tools\" <span class=\"eyebrow\" Concurrent workers per tool</span <div class=\"dv-bars\" style=\"margin-top: 0.8rem\" <span",
   "quote": "The slow row is honest: code search over a large index at two thousand concurrent callers is bound by the database, and the numbers say so.",
   "evidence": [
    "Load testing with AI agent fleets: 2,000 concurrent AI workers on a memory and code-intelligence service on one workstation, with 0 failures.",
    "Capacity engineering and backpressure: every endpoint bounded, a reranker that saturates instead of erroring, and a dedicated pool so observation writes never compete with reads.",
    "Retrieval service performance: 1,479 requests a second held in keyword mode from a floor of 1,271; repeat questions answered from cache in under 100 milliseconds.",
    "Rust and PostgreSQL service design: a precomputed code graph, so a dependency trace under load is a bounded traversal rather than a model call."
   ],
   "problem": "governed-agents"
  },
  {
   "url": "https://coreyjames.ai/stories/built-for-blackwell/",
   "kind": "story",
   "title": "Built for Blackwell",
   "subtitle": "CUDA 13 on a Blackwell GPU at the bench, with a provisioning path that reaches datacentre Blackwell capacity in the cloud, and an honest line about what carries over",
   "systems": [
    "inference-fabric",
    "fafo-core"
   ],
   "technologies": [
    "CUDA Driver API",
    "CUDA C++",
    "NVIDIA Blackwell GPUs",
    "NVIDIA TensorRT-LLM",
    "Federated compute provisioning",
    "RunPod"
   ],
   "stats": [
    {
     "value": "300",
     "label": "lines of safe Rust over the CUDA 13 driver API"
    },
    {
     "value": "64 × 128",
     "label": "lattice search tile in use, chosen over a 128-row tile"
    },
    {
     "value": "32",
     "label": "minimum rows per cell, bounding float-atomic contention"
    },
    {
     "value": "3",
     "label": "budget warnings, at 80, 90 and 95 percent, before the gate denies"
    }
   ],
   "lede": "My GPU work targets NVIDIA's Blackwell generation from the toolchain up. The CUDA engine builds with CUDA 13.1 and compiles every kernel to native SM 120 binaries, the consumer Blackwell architecture of both cards, with no PTX embedded and no just-in-time path to another architecture. The inference runtime's TensorRT-LLM image is built for the same target. And the provisioning path that stands up a GPU consumer node can ask a cloud provider for datacentre Blackwell capacity through the same call that starts a container on my workbench, under a budget gate that an agent cannot raise. Why the driver API When I started, no Rust CUDA crate supported CUDA 13 or SM 120. Instead of waiting I generated bindings over",
   "quote": "The engine's job is to produce numbers I can verify.",
   "evidence": [
    "NVIDIA Blackwell development: CUDA 13.1 kernels compiled to native SM 120 binaries with no PTX, behind a test gate that refuses any device whose compute capability is not exactly 12.0.",
    "Rust systems engineering: 300 lines of safe Rust over the CUDA 13 driver API, written when no Rust CUDA crate supported the new generation.",
    "Cloud GPU provisioning with cost controls: one call stands up a GPU consumer node behind a budget gate, with 3 warnings at 80, 90 and 95 percent before it denies.",
    "CUDA kernel development: a 64 x 128 lattice search tile and a minimum of 32 rows per cell to bound float-atomic contention."
   ],
   "problem": "gpu-economics"
  },
  {
   "url": "https://coreyjames.ai/stories/one-call-to-a-gpu-anywhere/",
   "kind": "story",
   "title": "One call to a GPU anywhere",
   "subtitle": "Provisioning a GPU consumer node on the workbench, on a LAN host or in the cloud with one tool call, under a daily budget that only a human can set",
   "systems": [
    "fafo-core",
    "inference-fabric",
    "agentos"
   ],
   "technologies": [
    "Federated compute provisioning",
    "Budget enforcement and cost governance",
    "Docker",
    "TLS and mTLS",
    "Redis",
    "PostgreSQL",
    "RunPod"
   ],
   "stats": [
    {
     "value": "15",
     "label": "actions on the one provisioning tool"
    },
    {
     "value": "0",
     "label": "inbound ports for a cloud pod to reach the estate"
    },
    {
     "value": "30 s",
     "label": "between budget checks on every container, healthy ones included"
    },
    {
     "value": "$0",
     "label": "the day's budget when no limit row exists"
    }
   ],
   "lede": "An agent in my estate can stand up a GPU worker with one tool call: a container image, an engine, a provider, and where it should run. The same call starts a container on my workbench over the local socket, on a LAN workstation over mutual TLS, or on a rented cloud pod that dials back into my network with no inbound ports. Before any of that happens, a budget gate checks the day's dollar cap, which is set by a human with a command-line tool that is not on any agent's tool surface. Spend is metered from the second the provider confirms the pod, and a container that outlives the budget is terminated. One call The provisioning tool takes",
   "quote": "Missing or invalid state can only yield zero or an error, never a larger cap.",
   "evidence": [
    "Cloud GPU provisioning with cost controls: one tool with 15 actions stands up a GPU worker on the workbench, a LAN host or a rented cloud pod.",
    "Zero-trust and zero-inbound networking: cloud pods dial back through an outbound tunnel, reaching Redis and PostgreSQL with 0 inbound ports; LAN hosts are driven over mutual TLS from a private certificate authority.",
    "Budget enforcement for AI agents: a daily dollar cap set only by a human command-line tool, checked before any side effect, failing closed at $0 when no limit row exists.",
    "Metering and reconciliation: spend accumulated per container, per schema and globally, with health checks every 30 s that terminate any container still up once the budget is spent.",
    "Container runtime design: one host-built runtime binary bind-mounted with a loader into any image, and four loader modes that decide what a container becomes."
   ],
   "problem": "gpu-economics"
  },
  {
   "url": "https://coreyjames.ai/stories/several-minds-in-one-room/",
   "kind": "story",
   "title": "Several minds in one room",
   "subtitle": "A team chat where humans and several model seats work together, each seat answering only when addressed, with no loop an agent can start",
   "systems": [
    "helix",
    "fafohive"
   ],
   "technologies": [
    "Mattermost",
    "Rust",
    "PostgreSQL",
    "Context engineering and persistent agent memory",
    "Idempotency, exactly-once effects and crash recovery"
   ],
   "stats": [
    {
     "value": "8",
     "label": "fixed model seats, plus Helix itself"
    },
    {
     "value": "3",
     "label": "model families behind those seats"
    },
    {
     "value": "30 s",
     "label": "deadline for a prompt to appear in the provider's own transcript"
    }
   ],
   "lede": "Most AI chat is one person and one model in a private window. My work is a team: several people, several models from different families, documents on the table, and decisions that have to outlive the session. Helix puts all of that in one room on an open-source team chat server. Each model is a named participant with its own identity. A person addresses a seat the way they address a colleague, the seat answers in the right thread under its own name, and the room keeps the history. The shell is replaceable The chat server runs unmodified from a pinned image, with its bundled calling and AI plugins switched off, so Helix is the only AI and voice authority",
   "quote": "The room is the authority, and no model holds the shared state.",
   "evidence": [
    "Multi-agent collaboration systems: people and 8 fixed model seats from 3 model families working in one chat room, each seat answering only when addressed.",
    "Exactly-once delivery and crash recovery: intake and output keyed so a retry repairs a missing post and never runs a model turn twice.",
    "Context engineering for LLM agents: each turn assembled from a bounded set of inputs, older context left in the seat's own session, credentials never in a prompt.",
    "Delivery verification for agent prompts: a prompt counts as delivered only when it appears in the provider's own transcript within 30 s."
   ],
   "problem": "collaboration"
  },
  {
   "url": "https://coreyjames.ai/stories/three-councils-i-threw-away/",
   "kind": "story",
   "title": "Three councils I threw away",
   "subtitle": "Four designs for several models deliberating toward one plan, and why only the one that behaves like a real group conversation survived real use",
   "systems": [
    "helix"
   ],
   "technologies": [
    "Mattermost",
    "Rust",
    "PostgreSQL",
    "Idempotency, exactly-once effects and crash recovery",
    "Governed AI-assisted software engineering"
   ],
   "stats": [
    {
     "value": "9",
     "label": "defects the first council surfaced in itself on its first real use"
    },
    {
     "value": "7",
     "label": "candidate revisions in one costing council before agreement"
    },
    {
     "value": "21 of 24",
     "label": "contribution slots committed when a mid-turn restart stalled a council"
    }
   ],
   "lede": "A council is Helix's answer to a question I kept running into: how do you get several strong models to deliberate toward a plan without one of them dominating, without a runaway loop, and with a human in control? I built it four times. The first three worked as software and failed as councils. All four protocols are still in the tree, because the rejections are where the judgment is. Opening a council Every version opens the same way. The operator presses a council button in the chat composer, or chooses to invoke a council about a particular post or file. A builder collects the problem, the seats, and the budgets. Any fixed seat can be chosen, duplicates allowed, each",
   "quote": "Each rejected council passed its tests.",
   "evidence": [
    "Consensus and deliberation protocols for AI agents: four council designs built and used, three rejected after real use, the survivor closing only on unanimous agreement with one revision.",
    "Defect discovery through real use: the first council surfaced 9 defects in itself on its first real use.",
    "Versioned agreement for AI planning: a costing council moved through 7 candidate revisions before agreement, each new revision invalidating earlier stances.",
    "Crash recovery in multi-agent sessions: a mid-turn restart left 21 of 24 contribution slots committed and the interrupted turns marked, with nothing lost."
   ],
   "problem": "collaboration"
  },
  {
   "url": "https://coreyjames.ai/stories/the-same-brain-typed-or-spoken/",
   "kind": "story",
   "title": "The same brain, typed or spoken",
   "subtitle": "Why a spoken request and a typed request produce exactly one durable turn in the same conversation, and what it took to keep the two from drifting apart",
   "systems": [
    "helix"
   ],
   "technologies": [
    "Real-time audio pipeline engineering",
    "Microsoft Teams",
    "Microsoft Entra ID",
    "Rust",
    "Idempotency, exactly-once effects and crash recovery"
   ],
   "stats": [
    {
     "value": "699 ms",
     "label": "from a spoken request to the synthesiser admitting the quick opener"
    },
    {
     "value": "2",
     "label": "models: a light one keeps speech fast, the heavy brain does the work"
    },
    {
     "value": "4",
     "label": "identities: operator, employee, seat, voice session"
    }
   ],
   "lede": "Talking to Helix and typing to Helix reach the same conversation and the same history. That sounds like a feature. It is a constraint, and it ruled out the obvious design. The obvious design points the voice engine's model endpoint at the control centre, so speech becomes just another client. I rejected it because it discards turn identity: the voice engine generates speculatively, retries, and interrupts, and each of those would have become a duplicate piece of durable work in the conversation. design <figure class=\"dv-figure\" aria-label=\"The rejected design duplicates work; the bridge keeps one turn\" <div class=\"dv-two\" <div <span class=\"eyebrow\" Rejected · speech as one more client</span <div style=\"display: flex; flex-direction: column; gap: 10px; margin-top: 0.8rem\" <div style=\"display: flex; flex-wrap:",
   "quote": "A spoken projection can never outrun the written answer.",
   "evidence": [
    "Real-time voice AI: spoken and typed requests produce exactly one durable turn in the same conversation, and an interruption cancels that exact turn.",
    "Latency engineering for voice AI: 699 ms from a spoken request to the synthesiser admitting the quick opener, with a light model keeping speech fast and a heavy one doing the work.",
    "Identity separation in AI systems: operator, employee, seat and voice session kept as 4 identities that never merge, so each can change without touching the others."
   ],
   "problem": "collaboration"
  },
  {
   "url": "https://coreyjames.ai/stories/from-a-conversation-to-a-work-order/",
   "kind": "story",
   "title": "From a conversation to a work order",
   "subtitle": "Helix wraps my governance platform without modifying it: talk happens in the room, durable work goes through the platform's own commands, and results come back",
   "systems": [
    "helix",
    "agentos",
    "fafohive"
   ],
   "technologies": [
    "Model Context Protocol (MCP)",
    "PostgreSQL",
    "Rust",
    "Governed AI-assisted software engineering",
    "Context engineering and persistent agent memory"
   ],
   "stats": [
    {
     "value": "1",
     "label": "platform system at a time, imported by its exact id"
    },
    {
     "value": "3",
     "label": "kinds of result that come back into the room"
    }
   ],
   "lede": "A conversation is where decisions get made. A work order is where work gets done. Helix sits between the two, and the rule that shapes it is written at the top of its charter: it is a wrapper over my governance platform, AgentOS. It consumes the platform's binaries, command line and work graph, and it never modifies them. Durable work and durable knowledge go to the platform's own primitives, work orders, the work graph and the memory service. Ephemeral conversation stays in the interface layer. Two directions Work can start on either side. Starting in Helix, the operator creates planning-only systems, projects and work orders, each with its channels, files and grounding. When a work order is later applied through",
   "quote": "There is never estate-wide retrieval by omission.",
   "evidence": [
    "Agent orchestration: a chat room that turns a conversation into a governed work order through the platform's own commands, never by writing to its database.",
    "Scoped retrieval for AI agents: context retrieved at the level of invocation, never estate-wide by omission, with writes only to the exact current scope.",
    "Grounding and context assembly: an immutable per-turn envelope carrying a grounding packet stamped with a revision watermark, rejected when the two disagree.",
    "Graceful degradation: only unresolvable ancestry is fatal; other memory sources degrade by name and the conversation carries on."
   ],
   "problem": "collaboration"
  },
  {
   "url": "https://coreyjames.ai/stories/engines-for-the-card-you-have/",
   "kind": "story",
   "title": "Engines for the card you have",
   "subtitle": "One calibrated FP8 checkpoint, a dozen inference engines sized to two consumer Blackwell GPUs, and the benchmarks that decided what the tiers would be",
   "systems": [
    "inference-fabric"
   ],
   "technologies": [
    "NVIDIA TensorRT-LLM",
    "NVIDIA TensorRT",
    "Model quantization",
    "GPU inference engine engineering",
    "KV-cache engineering",
    "Performance engineering and benchmarking",
    "Docker"
   ],
   "stats": [
    {
     "value": "7.5 GB",
     "label": "engine footprint on disk, every tier"
    },
    {
     "value": "3.5 s",
     "label": "engine load time"
    },
    {
     "value": "+56%",
     "label": "throughput at a 70 percent shared prefix on the larger card"
    },
    {
     "value": "6",
     "label": "lines changed in the vendor model graph"
    }
   ],
   "lede": "A built inference engine is a commitment to one GPU, one precision and one set of limits. It will load on that card and refuse any other, it holds exactly the batch and token budget it was built for, and it carries the key-value cache layout it was given. The fleet that reached 163,000 tokens per second in From 44K to 163K tokens per second ran on engines I built this way, a dozen of them from one checkpoint, each sized to the card in front of me. One checkpoint, many engines The model is a 7-billion-parameter dense instruction model. I quantize it once: FP8 weights and an FP8 key-value cache, calibrated, with the output head left in high precision.",
   "quote": "Those numbers are why the broker groups batches by prefix.",
   "evidence": [
    "TensorRT and TensorRT-LLM engineering: 12 engines from one quantized FP8 checkpoint, sized per card, each 7.5 GB on disk with a 3.5 s load.",
    "GPU inference optimisation: a token-budget tier sweep on the 32 GB card from 16,847 to 43,680 tokens per second.",
    "KV-cache engineering: caching measured on the real prompt structure, +56% throughput at a 70 percent shared prefix on the larger card.",
    "Hidden-state extraction from LLMs: 6 lines changed in the vendor model graph so every decoder model built from the tree exposes its hidden state."
   ],
   "problem": "gpu-economics"
  },
  {
   "url": "https://coreyjames.ai/stories/every-metric-gets-a-cpu-twin/",
   "kind": "story",
   "title": "Every metric gets a CPU twin",
   "subtitle": "Thirty-eight GPU cluster metrics defined by a nine-thousand-line CPU reference library, and a three-way consistency check between kernels, references and documentation",
   "systems": [
    "inference-fabric"
   ],
   "technologies": [
    "CUDA C++",
    "Rust",
    "Determinism and numerical reproducibility",
    "GPU numerical kernel design",
    "ML evaluation methodology"
   ],
   "stats": [
    {
     "value": "9,000",
     "label": "lines of plain Rust that define every metric"
    },
    {
     "value": "32",
     "label": "Rust integration tests, plus fifteen CUDA test files"
    },
    {
     "value": "3",
     "label": "spectral metrics that exist only as the CPU reference"
    }
   ],
   "lede": "A GPU kernel that computes a statistic is a poor definition of that statistic. It is tuned for throughput and it reorders its reductions. So every metric my CUDA engine computes exists twice: once as a kernel and once as plain Rust on the CPU, and the CPU version is the definition. The reference library is about 9,000 lines across thirteen modules, cohesion, diversity, substructure, spatial, dual-space, quantum, spectral, sigma, composites, exact search and top-k among them. The kernels are checked against it, and the documentation is checked against both. What the twin is for The reference is written for clarity, not speed, so a reader can confirm the formula by inspection. It is also where the edge cases are",
   "quote": "When a kernel is wrong, it is wrong at speed.",
   "evidence": [
    "Numerical verification of GPU code: every GPU metric checked against a CPU reference, about 9,000 lines of plain Rust that defines each metric.",
    "Test engineering for CUDA: 32 Rust integration tests and fifteen CUDA test files, with tolerances derived from the arithmetic rather than tuned to pass.",
    "Deterministic GPU computation: search results held to zero tolerance by position tie-breaks and a seeded host-side draw."
   ],
   "problem": "proof"
  },
  {
   "url": "https://coreyjames.ai/stories/removing-the-sampling-caps/",
   "kind": "story",
   "title": "Removing the sampling caps",
   "subtitle": "From kernels that looked at fifty members and twelve hundred pairs to exact statistics over a hundred thousand members, by redesigning every kernel into one of three scaling classes",
   "systems": [
    "inference-fabric"
   ],
   "technologies": [
    "CUDA C++",
    "GPU numerical kernel design",
    "Performance engineering and benchmarking",
    "NVIDIA Blackwell GPUs"
   ],
   "stats": [
    {
     "value": "1,225",
     "label": "pairs the old pairwise statistics were capped at"
    },
    {
     "value": "2,000",
     "label": "member limit for Gram-bounded kernels, refused above it"
    },
    {
     "value": "6",
     "label": "accumulator types in the shared tile library"
    },
    {
     "value": "20",
     "label": "legacy kernels kept, with sixteen tests against the references"
    }
   ],
   "lede": "The first generation of my cluster-metric kernels cheated, and I knew it. A cluster of a hundred thousand embeddings was scored from a sample of fifty members. The two-means split and the silhouette ran on fifty-member subsets. This is the story of taking every cap out. design <blockquote class=\"dv-quote\" <p The numbers came back fast and they were estimates of the thing I wanted rather than the thing itself.</p </blockquote Why the caps were there The early kernels were written one metric at a time, each with its own loop over members, each accumulating into global memory with atomics. At fifty members, contention on those atomics was invisible. At a hundred thousand it would have dominated, and a pairwise kernel",
   "quote": "The numbers came back fast and they were estimates of the thing I wanted rather than the thing itself.",
   "evidence": [
    "CUDA kernel development: every cluster-metric kernel sorted into three scaling classes, with Gram-bounded kernels refusing clusters above 2,000 members instead of sampling.",
    "Embedding analytics and cluster metrics: pairwise statistics once capped at 1,225 pairs computed on every pair, for clusters of up to 100,000 members.",
    "GPU performance engineering: a shared tile library with 6 accumulator types, and the centroid family at 46.67 ms for 100,000 members.",
    "Regression testing for kernels: 20 legacy kernels kept, with sixteen tests against the CPU references, so each rewrite has a baseline."
   ],
   "problem": "embedding-analytics"
  },
  {
   "url": "https://coreyjames.ai/stories/where-a-cluster-sits/",
   "kind": "story",
   "title": "Where a cluster sits",
   "subtitle": "Ten neighbourhood metrics that place each cluster among the clusters around it, computed from precomputed neighbour lists in a handful of GPU launches",
   "systems": [
    "inference-fabric"
   ],
   "technologies": [
    "CUDA C++",
    "GPU numerical kernel design",
    "Hybrid retrieval",
    "FAISS"
   ],
   "stats": [
    {
     "value": "6",
     "label": "values from one sorted row, one thread per cluster"
    },
    {
     "value": "0",
     "label": "distance computations inside the cluster-level kernels"
    },
    {
     "value": "24 KB",
     "label": "shared memory for a cluster's own and five neighbour centroids"
    },
    {
     "value": "2",
     "label": "metrics that need every member"
    }
   ],
   "lede": "Most cluster statistics look inward: how tight, how spread, how many sub-groups. The questions that decide what to do with a cluster look outward. Is it crowded by neighbours or alone? Do its members belong to it or to the cluster next door? Does it sit on the topic its neighbours share, or off it? Has it drifted from the group it was part of? My engine answers those with a neighbourhood family of metrics that runs from precomputed neighbour lists, so none of the kernels has to search. The neighbour lists For every cluster, an approximate-nearest-neighbour index over the centroids returns a sorted row of the twenty nearest clusters and their distances, with the cluster itself at position zero.",
   "quote": "The comparison is the same and the square root is wasted work.",
   "evidence": [
    "Embedding analytics and cluster metrics: ten neighbourhood metrics per cluster from precomputed neighbour lists, with 0 distance computations inside the cluster-level kernels.",
    "CUDA kernel development: a member-level kernel caching a cluster's own and five neighbour centroids in 24 KB of shared memory, 231.82 ms at 100,000 members.",
    "Vector search and ANN indexes: an approximate nearest-neighbour index over centroids giving each cluster a sorted row of its 20 nearest clusters."
   ],
   "problem": "embedding-analytics"
  },
  {
   "url": "https://coreyjames.ai/stories/diversity-in-three-kernels/",
   "kind": "story",
   "title": "Diversity in three kernels",
   "subtitle": "Why entropy over pairwise distances needs a second pass, and how redundancy, information density, coverage and concept breadth come out of the same tiles",
   "systems": [
    "inference-fabric"
   ],
   "technologies": [
    "CUDA C++",
    "GPU numerical kernel design",
    "Determinism and numerical reproducibility"
   ],
   "stats": [
    {
     "value": "16 × 64",
     "label": "pair tiles, one atomic per tile for the minimum and maximum"
    },
    {
     "value": "20",
     "label": "histogram bins in shared memory, flushed once per block"
    },
    {
     "value": "5 B",
     "label": "pairwise distances recomputed rather than stored"
    },
    {
     "value": "1",
     "label": "entropy score for a perfectly even spread"
    }
   ],
   "lede": "A cluster of embeddings can be tight and still be useless, because every member says the same thing. The diversity family measures the opposite of redundancy: how much of the cluster is distinct, how evenly its members are spread, and how broad the concept it covers is. Five of those metrics come from pairwise distances, and one of them, entropy, forced the design into three kernels where one would have been nicer. The problem with entropy Entropy of the pairwise distances needs a histogram, and a histogram needs its bin edges before the first distance is counted. The edges come from the minimum and maximum distance in the cluster, which are not known until every pair has been visited. design",
   "quote": "One pass cannot do both.",
   "evidence": [
    "CUDA kernel development: a diversity family split into a statistics pass, a histogram pass and a finalize, because entropy needs its range before its bins.",
    "GPU numerical methods: float minimum and maximum carried as compare-and-swap loops with one atomic per 16 x 64 tile, and a 20-bin shared-memory histogram.",
    "Embedding analytics and cluster metrics: entropy, coverage, redundancy, information density and concept breadth from the same tiles, thresholds fixed at 0.9 and 0.85 so scores compare across runs.",
    "GPU memory trade-offs: 5 billion pairwise distances recomputed rather than stored."
   ],
   "problem": "embedding-analytics"
  },
  {
   "url": "https://coreyjames.ai/stories/physics-as-a-lens-on-embeddings/",
   "kind": "story",
   "title": "Physics as a lens on embeddings",
   "subtitle": "A characteristic length scale from a histogram median, then potential depth, curvature, escape probability, superposition, interference and entanglement as cluster metrics",
   "systems": [
    "inference-fabric"
   ],
   "technologies": [
    "CUDA C++",
    "GPU numerical kernel design",
    "ML evaluation methodology"
   ],
   "stats": [
    {
     "value": "256",
     "label": "histogram bins find each cluster's median distance"
    },
    {
     "value": "0.4%",
     "label": "resolution of the median, with no distance ever stored"
    },
    {
     "value": "2,000",
     "label": "member cap on the three spectral metrics, kept on the CPU"
    }
   ],
   "lede": "Distances between embeddings are the raw material of every cluster metric, and most metrics use them directly. I wanted a family that treated a cluster as a field: each member a point charge, the centroid a probe, and the shape of the resulting potential as the description of the cluster. The vocabulary is borrowed from physics, the formulas are plain Gaussian kernels, and the metrics turned out to say things the direct statistics do not. The length scale first A Gaussian kernel needs a width, and a fixed width would make the metrics depend on the embedding model's scale. So each cluster gets its own characteristic scale: a constant times the median of its pairwise distances. The median of millions",
   "quote": "I kept them out of the GPU count rather than put a kernel with a silent size limit on the card.",
   "evidence": [
    "Embedding analytics and cluster metrics: physics-style field metrics for embedding clusters, depth, curvature, escape probability, superposition and interference, computed in one streaming pass over the members.",
    "CUDA kernel development: each cluster's length scale found from a 256-bin shared-memory histogram of its pairwise distances, at 0.4% resolution with no distance ever stored.",
    "Quadratic GPU kernels without materialised matrices: entanglement computed over a tiled upper triangle of member pairs with no Gram matrix formed.",
    "Engineering judgment on GPU limits: three spectral metrics kept as CPU reference code with a 2,000-member cap rather than a GPU kernel with a silent size limit."
   ],
   "problem": "embedding-analytics"
  },
  {
   "url": "https://coreyjames.ai/stories/two-means-as-a-measuring-instrument/",
   "kind": "story",
   "title": "Two-means as a measuring instrument",
   "subtitle": "Exactly three Lloyd iterations, seeded at the first and last member, as the fixed definition behind clustering tendency, fragmentation, sub-cluster count and silhouette",
   "systems": [
    "inference-fabric"
   ],
   "technologies": [
    "CUDA C++",
    "GPU numerical kernel design",
    "Determinism and numerical reproducibility"
   ],
   "stats": [
    {
     "value": "4",
     "label": "cluster metrics read from one fixed split"
    },
    {
     "value": "0.5M",
     "label": "members per second, about half a million, linear in size"
    },
    {
     "value": "1.2 ms",
     "label": "or less for the silhouette on the clusters it meets"
    }
   ],
   "lede": "Does this cluster want to be two clusters? The usual answer is to run k-means with k equal to two and look at the result, and the usual problem is that k-means is an optimiser: it runs until it converges, converges somewhere different depending on its seeds, and gives a different answer on a different day. I wanted the answer to be a metric, which means a fixed procedure with a fixed result. So the two-means split in my engine is defined as a measuring instrument, and four metrics read from it. The fixed procedure One block per cluster. A first pass computes the single-centroid inertia, the sum of squared distances to the cluster's own centroid. Two centroids are then",
   "quote": "A converged k-means gives a better split and a worse metric.",
   "evidence": [
    "Deterministic GPU computation: a fixed two-means procedure, first and last member as seeds and exactly three Lloyd iterations, so a cluster splits the same way on the GPU and in the CPU reference.",
    "CUDA kernel development: one block per cluster with no atomics and about 12 KB of shared memory, at about 0.5M members a second, linear in size.",
    "Embedding analytics and cluster metrics: four metrics read from one split, tendency, fragmentation, sub-cluster count and silhouette, the silhouette in 1.2 ms or less for the clusters it meets.",
    "Measurement design: a fixed instrument chosen over a converged optimiser, because a decision rule needs a number that is comparable across a corpus and across runs."
   ],
   "problem": "embedding-analytics"
  },
  {
   "url": "https://coreyjames.ai/stories/from-health-scores-to-decisions/",
   "kind": "story",
   "title": "From health scores to decisions",
   "subtitle": "Five composite scores built from the per-cluster metrics with weights that live in a database table, feeding the pressure model that decides what the corpus does next",
   "systems": [
    "inference-fabric"
   ],
   "technologies": [
    "PostgreSQL",
    "Rust",
    "ML evaluation methodology",
    "SQL"
   ],
   "stats": [
    {
     "value": "38",
     "label": "raw metrics per cluster, a diagnosis rather than a decision"
    },
    {
     "value": "2,000",
     "label": "members, above which the spectral metrics are left null"
    },
    {
     "value": "1 row",
     "label": "per composite and metric holds every weight"
    }
   ],
   "lede": "Thirty-eight metrics per cluster is a diagnosis. The decisions, split this cluster, merge those two, leave that one alone, are made inside the database by a pressure model, and the pressure model reads five composite scores rather than thirty-eight raw values. This is how the composites are built and why their weights are data rather than code. Five composites Each composite is a weighted average over a named subset of the metrics, and each subset answers one question about the cluster. design <figure class=\"dv-figure\" aria-label=\"The five composites and how many metrics each reads\" <span class=\"eyebrow\" Five composites · metrics read by each</span <div class=\"dv-bars\" style=\"grid-template-columns: 9.5rem minmax(0, 1fr) 2.5rem\" <span Overall health</span <span <span class=\"bar on\" style=\"width: 100%\" </span </span",
   "quote": "A composite that treated a missing value as zero would punish the cluster for the gap.",
   "evidence": [
    "Embedding analytics and cluster metrics: 38 raw metrics per cluster folded into five composite health scores that a pressure model reads to split, merge or hold a cluster.",
    "Robust scoring with missing data: skip-null averaging that renormalises over the weights present and stores the metric count beside each composite instead of reading a gap as zero.",
    "Configuration as audited data: composite weights held as one row per composite and metric in PostgreSQL, read by both the CPU reference and the SQL that computes the composites.",
    "Data-driven automation: typed functions inside the database act on split, merge and hold pressures derived from kernel metrics, every step reproducible from the metric definitions."
   ],
   "problem": "embedding-analytics"
  },
  {
   "url": "https://coreyjames.ai/stories/shapes-have-a-lifecycle/",
   "kind": "story",
   "title": "Shapes have a lifecycle",
   "subtitle": "Every switch of prompt shape costs a GPU its prefix cache, so the broker stages a shape until it is worth running, warms the next one before the current one drains, and alarms when a shape ran too briefly",
   "systems": [
    "inference-fabric"
   ],
   "technologies": [
    "Token-aware GPU batch scheduling",
    "KV-cache engineering",
    "Rust",
    "State machine design for multi-agent workflows"
   ],
   "stats": [
    {
     "value": "5",
     "label": "states every prompt shape moves through"
    },
    {
     "value": "99.9%",
     "label": "key-value hit rate in a five-minute two-GPU window"
    },
    {
     "value": "100",
     "label": "batches: a shape that finishes sooner is flagged as thrashing"
    }
   ],
   "lede": "A shape, in my broker, is a set of prompts that share the same ordered prefixes, which is what makes them cacheable together on the GPU. Switching from one shape to another throws away the engine's prefix cache and may force a rebuild of its CUDA graphs. A broker that interleaves shapes freely therefore pays that price constantly, and the engine spends its time rebuilding rather than generating. So shapes in my broker have a lifecycle, and the lifecycle is a state machine with thresholds, not a heuristic. Five states A new shape is staged. Its items accumulate per signature, and nothing is dispatched, because opening lanes for a handful of items wastes structure the engine could use. Items that",
   "quote": "Draining shapes never take new items, which is the invariant the whole design rests on.",
   "evidence": [
    "Token-aware scheduling: prompt shapes with a state-machine lifecycle, staged, active, draining and finished, so the GPU's prefix cache and CUDA graphs are rebuilt only when a switch is worth it.",
    "GPU inference optimisation: a pre-warm signal names the next shape and lane so graphs are built before the switch, with a 99.9% key-value hit rate in a five-minute two-GPU window.",
    "Observability and alerting: a thrashing alarm for any shape that finishes in fewer than 100 batches, and lane starvation counted as a metric rather than seen as slow batches."
   ],
   "problem": "gpu-economics"
  },
  {
   "url": "https://coreyjames.ai/stories/the-128-lane-wall/",
   "kind": "story",
   "title": "The 128-lane wall",
   "subtitle": "Padding waste ran under one percent until every shape used all of its 128 lanes, then climbed past 95 percent on a 22-million-item load test; the fix was structural",
   "systems": [
    "inference-fabric"
   ],
   "technologies": [
    "Token-aware GPU batch scheduling",
    "Rust",
    "Performance engineering and benchmarking",
    "Capacity engineering, backpressure and load testing"
   ],
   "stats": [
    {
     "value": "10B",
     "label": "tokens in the 22-million-item load test that found the wall"
    },
    {
     "value": "0.421%",
     "label": "padding waste in the two-GPU window after the fix"
    },
    {
     "value": "8",
     "label": "phases of changes to widen the lane id"
    }
   ],
   "lede": "My broker packs prompts of similar length into lanes so that a batch pads as little as possible. Each lane has a target length, items go to the lane that wastes the least, and a new lane opens when the waste would be too high. The first version gave each shape 128 lanes, because the lane id was a byte and 128 seemed like plenty. A load test showed exactly what plenty was worth. The curve As the run went on, every shape reached a hundred percent lane pressure, meaning every one of its 128 lanes was in use and no new lane could open. The broker was doing exactly what it was designed to do: with no lane free,",
   "quote": "Tuning the waste threshold could not help, because the threshold only decides when to open a lane, and no lane could be opened.",
   "evidence": [
    "Performance diagnosis: traced padding waste of 95%+ on a 22-million-item load test to a structural budget of 128 lanes per shape, a capacity limit that no threshold tuning could fix.",
    "Token-aware scheduling: widened the lane id to 16 bits across 8 phases of changes, raising the budget to 2,048 lanes so the pressure-scaled waste threshold could work.",
    "GPU inference optimisation: padding waste at 0.421% in the two-GPU window after the fix, with average lane pressure at 22% instead of 100%."
   ],
   "problem": "gpu-economics"
  },
  {
   "url": "https://coreyjames.ai/stories/done-means-delivered/",
   "kind": "story",
   "title": "Done means delivered",
   "subtitle": "A result counts as delivered only after it has been written to the receiver's socket, and polling a job costs what is ready rather than what is pending",
   "systems": [
    "inference-fabric"
   ],
   "technologies": [
    "Append-only log and journal design",
    "Idempotency, exactly-once effects and crash recovery",
    "Rust",
    "Binary wire protocol design"
   ],
   "stats": [
    {
     "value": "1 scan",
     "label": "rebuilds every result after a restart"
    },
    {
     "value": "1 job id",
     "label": "set once per connection scopes every poll"
    }
   ],
   "lede": "The input side of my broker is told in Millions of queued items that were not there: two-phase dispatch and in-place tombstones made the count of tokens received equal the count routed, to the token. The output side had the same disease in mirror image. A result could be marked finished, handed to a poller, and lost between the broker's memory and the receiver's hands. So the completion side got the same discipline, and polling got a data structure that scales with what is ready. A log for results Results from the GPUs are written to completion segments, append-only files. Recovery after a restart is a scan of those segments, so a result that reached disk is never forgotten by",
   "quote": "A result can be re-offered, and it is never silently gone.",
   "evidence": [
    "Exactly-once delivery and crash recovery: a result counts as delivered only after it is flushed to the receiver's socket and confirmed, so a receiver that dies is offered the same results again.",
    "Append-only log design: results written to completion segments that 1 scan rebuilds after a restart, with a committed offset as the readable boundary.",
    "Message broker and queue design: a job id set once per connection and job-scoped ready queues, so a poll costs what is ready rather than the whole pending backlog."
   ],
   "problem": "data-paths"
  },
  {
   "url": "https://coreyjames.ai/stories/recovery-that-trusts-only-what-happened/",
   "kind": "story",
   "title": "Recovery that trusts only what happened",
   "subtitle": "Tombstones as the single source of truth, a parallel scan on restart, a stale entry rewound before it is forgotten, a reconnecting GPU that reports what it still holds, and advisory checks that may never decide",
   "systems": [
    "inference-fabric"
   ],
   "technologies": [
    "Idempotency, exactly-once effects and crash recovery",
    "Append-only log and journal design",
    "Rust",
    "Distributed systems reliability"
   ],
   "stats": [
    {
     "value": "3",
     "label": "kinds of interruption, each once a path to loss or duplicate work"
    },
    {
     "value": "1 rule",
     "label": "recovery believes only what physically happened"
    },
    {
     "value": "100 ms",
     "label": "between tombstone flushes to disk"
    }
   ],
   "lede": "A broker that holds tens of millions of queued items on disk has to survive three kinds of interruption: its own restart, a GPU consumer disconnecting mid-batch, and an item that was admitted for dispatch and then never heard of again. Each of those had, at one point, a path to permanent loss or duplicate work. The design that closed them rests on one rule: recovery believes only evidence of events that physically happened, and nothing that was merely intended. The durability model behind it is one of my filed inventions, Family Two, and this is how it behaves in the broker. Tombstones are the truth When a GPU completes an item, the broker writes a tombstone over that item's",
   "quote": "An offset says how far dispatch had reached; a tombstone says what was finished.",
   "evidence": [
    "Exactly-once delivery and crash recovery: restart recovery that believes only tombstones written by completions and ignores persisted offsets, so an item past the offset but unfinished is never lost.",
    "Distributed systems correctness: stale or disconnected work reclaimed by rewinding the readable offset before dropping the pending entry, the rewind bounded by what was outstanding.",
    "Resilient GPU consumers: a consumer SDK that keeps working while the broker is away and re-registers the sequence ids it still holds, ending duplicate work after reconnects.",
    "Message broker and queue design: an advisory index demoted to logging after it starved a GPU with a full backlog on disk; only the authoritative segment read decides."
   ],
   "problem": "data-paths"
  },
  {
   "url": "https://coreyjames.ai/stories/starting-full-and-ending-clean/",
   "kind": "story",
   "title": "Starting full and ending clean",
   "subtitle": "A pressure gate holds dispatch until the first batches can be good, every batch closes on its token budget, and a cleanup mode drains the tail when the GPUs go quiet",
   "systems": [
    "inference-fabric"
   ],
   "technologies": [
    "Token-aware GPU batch scheduling",
    "Rust",
    "Performance engineering and benchmarking",
    "Prometheus"
   ],
   "stats": [
    {
     "value": "523 µs",
     "label": "average time to assemble a batch"
    },
    {
     "value": "~100%",
     "label": "batch fill at the median, the ninetieth and the ninety-ninth percentile"
    },
    {
     "value": "4",
     "label": "integers each GPU registers: batch size, tokens, input length, model"
    }
   ],
   "lede": "A batching broker is judged on its steady state, and its steady state is the easy part. The beginning and the end of a workload are where batches get small, caches get rebuilt and GPUs sit idle, and both needed their own mechanism. The release gate At the start of a run, items trickle in. A broker that dispatches the first trickle produces tiny batches and poor graph reuse, and the engine spends its first minutes doing badly what it could do well a moment later. So nothing is dispatched until staged and lane tokens together reach a release threshold. design <figure class=\"dv-figure\" aria-label=\"The release gate: tokens build to the threshold, then dispatch begins with full batches\" <div class=\"dv-two\" <div",
   "quote": "Once open, the gate stays open for the life of the process; it is a start condition rather than a throttle.",
   "evidence": [
    "Token-aware scheduling: a release gate that holds dispatch until staged and lane tokens reach a threshold, so the first batches of a run are full.",
    "High-throughput batch inference: every batch in a two-GPU run closed on its token budget, at about 100% fill at the median and tail percentiles, assembled in 523 µs on average.",
    "Lock-free shared-memory IPC: same-host batches through a ring on huge pages with a compare-and-exchange claim loop, offset-addressed batches and read-only mapping by the consumer.",
    "Workload tail handling: a cleanup mode with activation threshold 0 and a minimum batch of 1 that drains staged shapes and short lanes when the GPUs go quiet."
   ],
   "problem": "gpu-economics"
  },
  {
   "url": "https://coreyjames.ai/stories/twenty-thousand-rows-a-second/",
   "kind": "story",
   "title": "Twenty thousand rows a second",
   "subtitle": "A batch update that took twenty-five seconds became a third of a second: one SQL rewrite that makes parameter count independent of row count, and nearly 400 GB of indexes that nobody had ever read",
   "systems": [
    "postgresql-fabric",
    "fafo-core",
    "inference-fabric"
   ],
   "technologies": [
    "PostgreSQL",
    "SQL",
    "pgvector",
    "Database performance diagnosis",
    "Rust",
    "sqlx"
   ],
   "stats": [
    {
     "value": "0.3 s",
     "label": "per batch update, down from 25 s, with more rows in each"
    },
    {
     "value": "20,000",
     "label": "rows per second, up from 50, read from the database's own counters"
    },
    {
     "value": "0.19 ms",
     "label": "per row at most after the rewrite, and as low as 0.06 ms"
    }
   ],
   "lede": "My research pipeline writes its results back to PostgreSQL through one governed write path, and in a 3.4-million-item run that path was the bottleneck. Each batch update of about 1,350 rows cost roughly 19 milliseconds a row, and the queue behind it grew past 140,000 messages. Two changes fixed it: a different shape of UPDATE statement, and the removal of indexes that had never been used. The statement The original update built a table of values inline, joined it to the target and bound one parameter per cell. PostgreSQL allows 65,535 bind parameters per statement, so a twenty-column payload capped a batch at a few thousand rows, and the planner materialised the whole derived table before it could join. The",
   "quote": "A queue message is not a row.",
   "evidence": [
    "PostgreSQL performance tuning: a batch update cut from 25 s to 0.3 s by binding one array per column, with per-row cost of 0.06-0.19 ms.",
    "SQL query design: a parameter count independent of row count under PostgreSQL's 65,535 bind-parameter limit, with the old form kept as a fallback.",
    "Index cost analysis: never-scanned approximate-nearest-neighbour indexes found through two catalog queries and dropped, with recreation commands kept for rollback.",
    "Throughput measurement methodology: throughput read from the database's own tuple and commit counters, 50 to 20,000 rows per second, never from queue length."
   ],
   "problem": "data-paths"
  },
  {
   "url": "https://coreyjames.ai/stories/a-write-path-that-sizes-itself/",
   "kind": "story",
   "title": "A write path that sizes itself",
   "subtitle": "Batches sized from the payload's own width under PostgreSQL's parameter limit, writer workers that follow queue demand, and the batch-size knobs deliberately taken away from operators",
   "systems": [
    "postgresql-fabric",
    "fafo-core",
    "inference-fabric"
   ],
   "technologies": [
    "Write-behind persistence",
    "PostgreSQL",
    "Redis",
    "Capacity engineering, backpressure and load testing",
    "Rust"
   ],
   "stats": [
    {
     "value": "~240",
     "label": "updates per second each writer worker sustained in the benchmark"
    },
    {
     "value": "~1,929",
     "label": "updates per second held at eight workers"
    },
    {
     "value": "99.25%",
     "label": "buffer hit rate on that run, with I/O wait under 0.2 percent"
    }
   ],
   "lede": "Every function in my estate reads PostgreSQL directly and writes it through one service. Producers serialise each write into a stream message and move on; a writer service consumes the streams, groups messages by destination table and operation, and writes them in batched transactions at the pace the database can absorb. The interesting part is that nobody tells it how big a batch should be or how many workers to run. Batches sized from the payload PostgreSQL caps the bind parameters in one statement. A batch that exceeds the limit fails outright, and a batch far below it wastes round trips. The right batch size therefore depends on how many parameters each row binds, which depends on the destination and",
   "quote": "The fix moved the width to where it is known, the producer.",
   "evidence": [
    "Capacity engineering and load testing: writer pool bounds taken from a benchmark on a 24-core host, about 240 updates per second per worker, the CPU saturated above 16 workers.",
    "PostgreSQL performance tuning: batches sized from each payload's own width, fixing a sizing error that held one table at 3,640 rows per batch when it could take 10,000.",
    "Self-tuning systems design: batch-size settings removed from the operator surface, which keeps status, scaling bounds, presets and audited configuration.",
    "Write-behind persistence: about 1,929 updates per second held at eight workers with a 99.25% buffer hit rate."
   ],
   "problem": "data-paths"
  },
  {
   "url": "https://coreyjames.ai/stories/rules-that-never-ran/",
   "kind": "story",
   "title": "Rules that never ran",
   "subtitle": "The writer's batch-release rules had been silently unused, workers were grabbing whatever arrived, and 145 of 153 stream consumers were ghosts; how the write path was found out and rebuilt",
   "systems": [
    "postgresql-fabric",
    "fafo-core"
   ],
   "technologies": [
    "Redis",
    "Lua",
    "Write-behind persistence",
    "Database performance diagnosis",
    "Rust"
   ],
   "stats": [
    {
     "value": "8 of 153",
     "label": "registered stream consumers that were alive when measured"
    },
    {
     "value": "47+",
     "label": "stale consumers left behind by restarts"
    },
    {
     "value": "3",
     "label": "defects found at once"
    }
   ],
   "lede": "The write path had rules for when a batch should be released: enough messages for a destination, or enough age, with priorities so urgent writes went first. The rules were written in scripts that ran inside the queue store, and they were correct. They were also never consulted. Batches were arriving at the database in random sizes, with several workers contending for the same messages, and the throughput looked nothing like the design. Three defects The investigation found three things at once. Workers were reading new messages from the stream directly, which bypassed the release scripts entirely, so each worker took whatever had arrived since its last read. The scripts themselves read their rules from one configuration key while the",
   "quote": "The design was being ignored rather than violated.",
   "evidence": [
    "Distributed systems debugging: 3 defects found at once, a stream-read bypass, a misnamed configuration key and 47+ stale consumers, none of which raised an error.",
    "Observability and alerting: the batch-size distribution and consumer-against-process counts turned into metrics after they were the only evidence of the fault.",
    "Message broker and queue design: a write path rebuilt so the release rules are the only path, after only 8 of 153 registered consumers were found alive."
   ],
   "problem": "data-paths"
  },
  {
   "url": "https://coreyjames.ai/stories/pricing-writes-by-what-they-cost/",
   "kind": "story",
   "title": "Pricing writes by what they cost the database",
   "subtitle": "An admission controller that reads the database's own pressure, write-ahead-log rate, active writers and lock waits, and admits work only as fast as the database can take it",
   "systems": [
    "postgresql-fabric",
    "fafo-core",
    "inference-fabric"
   ],
   "technologies": [
    "Admission control and rate limiting",
    "PostgreSQL",
    "Redis",
    "Lua",
    "Rust"
   ],
   "stats": [
    {
     "value": "4",
     "label": "pressure signals, all read from the database's own statistics"
    },
    {
     "value": "3",
     "label": "modes: off, shadow and enforce"
    },
    {
     "value": "1",
     "label": "lattice-wide function running inside the database at a time"
    }
   ],
   "lede": "GPU-scale producers can push a database into trouble long before any query fails. The write path described in A write path that sizes itself keeps the database from being hammered by individual workers; the admission controller keeps the whole fleet from exceeding what the database can absorb. design <blockquote class=\"dv-quote\" <p It measures the database and spends the measurement.</p </blockquote Pressure, read from the database A sampler reads the database's own statistics, the write-ahead log, its writers, its locks and its statement statistics. Each signal is normalised between a healthy level and a critical one, and the signals are combined into one pressure index. The weights are tuned to this estate and stay private; the shape of the index does",
   "quote": "It measures the database and spends the measurement.",
   "evidence": [
    "Database admission control: an admission controller that combines 4 pressure signals from the database's own statistics, write-ahead log, writers, locks and statement statistics, into one pressure index for a GPU-scale fleet.",
    "Rate limiting: token buckets in log bytes, rows and write slots per lane and per schema that refill in full, partly or not at all by pressure band, with an atomic admit-or-hold check in the queue store.",
    "Distributed systems correctness: lattice-wide in-database functions held to 1 at a time under a lock with a heartbeat and a time-to-live, so a crashed holder cannot block the lane and a stale one cannot release it.",
    "Shadow-mode rollout: 3 modes, off, shadow and enforce, with shadow mode logging every decision without holding anything, so thresholds were set against real load before any write was refused.",
    "Multi-tenant fairness: schemas take turns so one tenant cannot monopolise the buckets, waiting batches gain priority with age, and a slow function throttles only its own writes."
   ],
   "problem": "data-paths"
  },
  {
   "url": "https://coreyjames.ai/stories/throughput-that-finished-nothing/",
   "kind": "story",
   "title": "Throughput that finished nothing",
   "subtitle": "The runtime reported more tokens per second than it ever had while finished sequences fell below one per second; the fix gated new work on how many sequences were already alive",
   "systems": [
    "inference-fabric"
   ],
   "technologies": [
    "NVIDIA TensorRT-LLM",
    "Token-aware GPU batch scheduling",
    "Rust",
    "C++",
    "Performance engineering and benchmarking"
   ],
   "stats": [
    {
     "value": "4,096",
     "label": "sequences per step on the largest engine tier"
    },
    {
     "value": "524,288",
     "label": "tokens per step on the same tier"
    },
    {
     "value": "~4,100",
     "label": "sequences active when nothing was finishing"
    }
   ],
   "lede": "The first time the runtime ran the largest engine tier I built for the dense 7B model under full load, the token rate and the completion counter disagreed. The GPU was generating at full speed and finishing nothing. What was happening Continuous batching lets the engine admit a new sequence into any step that has room. With no limit on admissions, the runtime filled every slot, and each step then advanced four thousand sequences by one token each. Every sequence made progress, so the token rate was real, and every sequence made progress so slowly that none of them reached its end. The workload needed finished sequences, with their outputs written back, and a steady state of four thousand half-finished",
   "quote": "Tokens per second is what an inference runtime advertises, and under a batch-oriented workload it can be maximised while delivering nothing.",
   "evidence": [
    "GPU inference optimisation: diagnosed a runtime generating at full speed while finishing fewer than one sequence a second with ~4,100 sequences active on a 4,096-sequence engine tier.",
    "Continuous batching admission control: a high-water and low-water latch on active slots that gates new prefills so the sequences in flight finish and free their slots.",
    "Inference runtime design in Rust and C++: batching duties split between halves, with continuing decodes always included and the token budget applied only to new prefills, held by a regression test.",
    "Backpressure design: a decode-loop ladder with a retry buffer served first, broker pulls bounded by free slots and oversized items failed back with empty output."
   ],
   "problem": "gpu-economics"
  },
  {
   "url": "https://coreyjames.ai/stories/a-second-engine-behind-the-same-door/",
   "kind": "story",
   "title": "A second engine behind the same door",
   "subtitle": "The vendor's executor could not run engines with no key-value cache or an extra output, so a raw-TensorRT backend went in behind the same C interface, and the Rust side never knew",
   "systems": [
    "inference-fabric"
   ],
   "technologies": [
    "NVIDIA TensorRT",
    "NVIDIA TensorRT-LLM",
    "C++",
    "Hidden-state extraction",
    "Contract-first interface design"
   ],
   "stats": [
    {
     "value": "8 KB",
     "label": "copied back to the host per sequence"
    },
    {
     "value": "128",
     "label": "tokens into a mining engine, for one forward pass"
    },
    {
     "value": "6 lines",
     "label": "changed in the vendor's model graph to gather the output to the last token"
    }
   ],
   "lede": "Hidden-state extraction needs an engine that generates nothing. I built those engines, in Engines for the card you have, and the vendor's executor refused to run them. design <figure class=\"dv-figure\" aria-label=\"How far each engine gets in the vendor executor\" <div style=\"display: grid; gap: 0.9rem; margin-top: 0.9rem\" <div <div style=\"display: flex; justify-content: space-between; gap: 0.8rem; font-size: 0.82rem; margin-bottom: 0.45rem\" <span A generation engine</span <span class=\"lbl\" style=\"color: inherit; text-align: right\" runs</span </div <div style=\"position: relative; height: 12px; border-radius: 6px; background: var(--rule)\" <i style=\"position: absolute; left: 0; top: 0; bottom: 0; width: 100%; border-radius: 6px; background: var(--tone)\" </i </div </div <div <div style=\"display: flex; justify-content: space-between; gap: 0.8rem; font-size: 0.82rem; margin-bottom: 0.45rem\" <span Mining engine: no key-value cache</span <span class=\"lbl\" style=\"color: var(--orange); text-align:",
   "quote": "I did not want the Rust half, the provisioner or the broker to know that mining engines were different.",
   "evidence": [
    "TensorRT and TensorRT-LLM engineering: a raw TensorRT backend behind the same C interface for engines with no key-value cache and an extra output, invisible to the Rust side.",
    "Hidden-state extraction: output gathered to the last token by a 6-line graph change, so a batch of 2,000 copies 16 MB to the host instead of 4 GB.",
    "Zero-allocation inference paths: every tensor checked and every buffer allocated once at load, each batch bound in three phases with nothing resolved by name at run time.",
    "Architecture discipline: a first mining path that cloned 13 MB per sequence across 1,600 sequences and copied 300 lines of start-up code was deleted for one path."
   ],
   "problem": "gpu-economics"
  },
  {
   "url": "https://coreyjames.ai/stories/asking-the-engine-what-it-meant/",
   "kind": "story",
   "title": "Asking the engine what it meant",
   "subtitle": "One input's convention was ambiguous in the vendor's documentation, and guessing wrong would silently extract the wrong token; so at startup the runtime runs a tiny batch both ways and refuses to start unless exactly one answer is consistent",
   "systems": [
    "inference-fabric"
   ],
   "technologies": [
    "NVIDIA TensorRT",
    "C++",
    "Hidden-state extraction",
    "Determinism and numerical reproducibility"
   ],
   "stats": [
    {
     "value": "3",
     "label": "tokens spent at startup to settle the question"
    },
    {
     "value": "2",
     "label": "runs of the same micro-batch, one per convention"
    },
    {
     "value": "64",
     "label": "output values checksummed per sequence"
    }
   ],
   "lede": "The mining engine takes an input that tells it which token's hidden state to gather for each sequence. The vendor's documentation leaves its convention open. design <figure class=\"dv-figure\" aria-label=\"What each wrong reading gathers: the second-to-last token or the next sequence's first\" <div class=\"dv-two\" <div <span class=\"eyebrow\" Sent the last index, read as a length</span <div style=\"display: flex; gap: 4px; margin-top: 0.9rem\" aria-hidden=\"true\" <span style=\"flex: 1; height: 26px; border-radius: 5px; background: var(--rule)\" </span <span style=\"flex: 1; height: 26px; border-radius: 5px; background: var(--rule)\" </span <span style=\"flex: 1; height: 26px; border-radius: 5px; background: var(--orange)\" </span <span style=\"flex: 1; height: 26px; border-radius: 5px; background: var(--surface); border: 2px solid var(--tone)\" </span <span style=\"width: 3px; background: var(--navy)\" </span <span style=\"flex: 1; height: 26px; border-radius: 5px; background:",
   "quote": "A systematic off-by-one would corrupt every vector in the same way, and the corruption would look like a slightly different model rather than a bug.",
   "evidence": [
    "Defensive integration with vendor runtimes: a startup self-test that runs a 3-token micro-batch under both readings of an ambiguous engine input and refuses to start unless exactly one is consistent.",
    "Data integrity for embedding corpora: hundreds of millions of hidden-state vectors guarded against a systematic off-by-one that would look like a different model rather than a bug.",
    "Numerical verification: checksums over the first 64 output values per sequence, decoded in software, with the proven convention frozen for the life of the process."
   ],
   "problem": "proof"
  },
  {
   "url": "https://coreyjames.ai/stories/the-thirteen-percent-that-was-never-missing/",
   "kind": "story",
   "title": "The thirteen percent that was never missing",
   "subtitle": "A profile said thirteen percent of the GPU was idle; it was the share of time in non-matrix kernels. Reading what each metric measured before optimising found utilisation at 98.7 percent",
   "systems": [
    "inference-fabric"
   ],
   "technologies": [
    "NVIDIA Nsight Systems",
    "GPU profiling and tracing",
    "Performance engineering and benchmarking",
    "NVIDIA TensorRT-LLM"
   ],
   "stats": [
    {
     "value": "98.7%",
     "label": "streaming-multiprocessor utilisation in the trace"
    },
    {
     "value": "332,965",
     "label": "kernel launches in sixty seconds"
    },
    {
     "value": "4,236",
     "label": "memory allocations, every one in the first second"
    }
   ],
   "lede": "An early profiling pass on the inference runtime reported a GPU compute efficiency figure and a gap, and the obvious next step was a programme of work to close the gap. Before starting it, I went back to the profile to find out what the number measured. It was the share of kernel time spent in matrix multiplications. The rest was attention, activation and normalisation kernels, all of them necessary, none of them idle. What the profile said A sixty-second trace on one consumer Blackwell GPU gave the whole picture. design <figure class=\"dv-figure\" aria-label=\"Where the kernel time went, and how much of the window had a kernel running\" <div class=\"dv-two\" <div <span class=\"eyebrow\" Share of kernel time</span <div class=\"dv-bars\" style=\"grid-template-columns:",
   "quote": "The habit that matters most in performance work: reading the definition of a metric before acting on its value.",
   "evidence": [
    "GPU profiling (Nsight): re-read a reported thirteen percent compute gap as necessary non-matrix kernel time and found streaming-multiprocessor utilisation at 98.7%.",
    "Performance benchmarking methodology: graph capture against eager execution measured at 30.77 against 30.81 billion nanoseconds of kernel time, and launch overhead dropped as a lever.",
    "Memory discipline in inference runtimes: 4,236 memory allocations in a sixty-second trace of 332,965 kernel launches, every allocation in the first second.",
    "Measurement discipline: a written rule to define each metric before reading it, compare like with like and write the cache configuration beside every figure."
   ],
   "problem": "proof"
  },
  {
   "url": "https://coreyjames.ai/stories/tests-that-passed-without-a-gpu/",
   "kind": "story",
   "title": "Tests that passed without a GPU",
   "subtitle": "Stub builds returned fake tokens and every test went green; the build now refuses to produce a binary without the real engine library, and the generation contract was fixed at the engine boundary before a corpus was reused",
   "systems": [
    "inference-fabric"
   ],
   "technologies": [
    "Rust",
    "C++",
    "NVIDIA TensorRT-LLM",
    "Static analysis as tests",
    "ML evaluation methodology"
   ],
   "stats": [
    {
     "value": "65,462",
     "label": "tokens in a rejected batch, under a 65,536-token limit"
    },
    {
     "value": "148",
     "label": "candidate sequences in that batch, nothing out of bounds"
    },
    {
     "value": "159 M",
     "label": "tokens dispatched upstream against an expected eight million"
    }
   ],
   "lede": "The inference runtime links a C++ library against the vendor's engine, and for a while the build could substitute a stub when the library was absent. The stub returned a fake token for every sequence, and the test suite passed against it. Two further bugs in the same period made the same point under real load. design <blockquote class=\"dv-quote\" <p A green suite that has never touched an engine is worse than no suite, because it says something true about the harness and nothing about the runtime.</p </blockquote The build that refuses The build script now refuses to produce a binary unless the real engine library is present, and stubs must be requested by name. The integration tests abort if",
   "quote": "A green suite that has never touched an engine is worse than no suite, because it says something true about the harness and nothing about the runtime.",
   "evidence": [
    "Test integrity for GPU software: a build that refuses to produce a binary without the real inference engine library, after a stub returning fake tokens let every test pass.",
    "TensorRT and TensorRT-LLM engineering: an executor rejecting every batch, 148 sequences and 65,462 tokens under a 65,536-token limit, fixed at the C++ request-building boundary.",
    "ML evaluation data hygiene: a replay corpus cleaned of end-of-sequence markers and prompt fragments before reuse, by stopping on the end-of-sequence token and excluding input from output.",
    "Distributed systems debugging: an upstream conductor dispatching 159 M tokens against an expected eight million, traced to a budget function imported and never called."
   ],
   "problem": "proof"
  },
  {
   "url": "https://coreyjames.ai/stories/machinery-i-built-and-then-did-not-need/",
   "kind": "story",
   "title": "Machinery I built and then did not need",
   "subtitle": "Fixed-size epochs and dense slots were built so decode steps could be captured as CUDA graphs; profiling showed the vendor's executor already does it. What I kept, what I stopped relying on, and the rule I took from it",
   "systems": [
    "inference-fabric"
   ],
   "technologies": [
    "NVIDIA TensorRT-LLM",
    "Rust",
    "GPU memory management",
    "Performance engineering and benchmarking"
   ],
   "stats": [
    {
     "value": "−6.8%",
     "label": "host key-value offload, set aside as a rejected idea"
    },
    {
     "value": "−7.5%",
     "label": "class-aware batching on average, also rejected"
    },
    {
     "value": "−36%",
     "label": "class-aware batching at peak"
    }
   ],
   "lede": "CUDA graphs capture a sequence of kernel launches once and replay it without launch overhead, and a decode loop that runs the same step hundreds of thousands of times looks like the ideal candidate. Capture has a condition, though: the shapes must be stable. So I built the machinery that would make the runtime's decode steps capturable. What was built An epoch is a span of steps with a fixed number of active slots. Slots are dense, so a batch of a given size always has the same layout; the map from sequence to slot is a bit vector with constant-time lookup; and a change in key-value-cache bucket falls back to eager execution for that step without ending the epoch.",
   "quote": "Read the library before reimplementing it, and measure before building the thing the measurement would justify.",
   "evidence": [
    "GPU profiling and performance analysis: CUDA graph replay measured against eager execution before capture was wired in, kernel time 30.77 against 30.81 billion nanoseconds.",
    "TensorRT and TensorRT-LLM engineering: established that the vendor's executor already captures and replays graphs internally, so the planned graph-capture work was dropped.",
    "Inference runtime design: epochs with a fixed slot count, dense slots and a constant-time bit-vector slot map, kept for slot integrity after their first purpose went away.",
    "Performance benchmarking methodology: rejected ideas kept with their measurements, host key-value offload at -6.8% and class-aware batching at -7.5% on average and -36% at peak."
   ],
   "problem": "proof"
  },
  {
   "url": "https://coreyjames.ai/stories/ghost-bytes-in-a-zero-copy-ring/",
   "kind": "story",
   "title": "Ghost bytes in a zero-copy ring",
   "subtitle": "A pinned-memory ring deadlocked with the GPU idle and hundreds of thousands of items in flight, because wrap-around padding was never freed; and a GPU worker that registered twice was starved as dead",
   "systems": [
    "inference-fabric"
   ],
   "technologies": [
    "GPU memory management",
    "Rust",
    "C++",
    "Distributed systems reliability"
   ],
   "stats": [
    {
     "value": "62,400",
     "label": "items dispatched and unresolved when the ring stalled"
    },
    {
     "value": "0",
     "label": "pending tokens at that moment, with the GPU idle"
    },
    {
     "value": "27",
     "label": "tests covering the event pool's checks"
    }
   ],
   "lede": "Batches reach the GPU through a hot queue in pinned host memory: mapped, write-combined, pre-faulted pages holding a ring of batch descriptors, with a doorbell the producer rings to publish and the GPU waits on. No copies, no allocation after warm-up, and one accounting error that stopped two GPUs. The deadlock When a batch does not fit before the end of the ring, the producer pads to the wrap point and writes the batch at the start. Every wrap left a few ghost bytes allocated and unreleasable, and over a long run they accumulated until the ring reported itself full with nothing in it, with a second consumer starving behind the first. The fix was a padding field on the",
   "quote": "Zero-copy and lock-free paths fail by accounting rather than by crashing, and the failures show up as a system that is quiet when it should be busy.",
   "evidence": [
    "Lock-free and zero-copy data paths: a pinned-memory ring between CPU and GPU deadlocked by wrap-around padding never released, fixed by a padding field the acknowledgement returns.",
    "Distributed systems debugging: a stall with 62,400 items dispatched and unresolved, 0 pending tokens and the GPU idle, traced to an accounting error rather than a crash.",
    "Message broker and queue design: each GPU worker registered once on one socket split into read and write halves that fail together, so working GPUs stop being declared dead.",
    "CUDA stream and event discipline: compute-stream synchronisation refused at run time and events drawn from a pool with generation counters and owner-thread checks, covered by 27 tests."
   ],
   "problem": "data-paths"
  },
  {
   "url": "https://coreyjames.ai/stories/an-index-you-can-rebuild-from-its-receipt/",
   "kind": "story",
   "title": "An index you can rebuild from its receipt",
   "subtitle": "Approximate-nearest-neighbour indexes are usually irreproducible, so a different result cannot be told from a bug; three hashes, a hash-seeded sample, fixed iterations and a byte-identical rebuild test make mine reproducible",
   "systems": [
    "inference-fabric"
   ],
   "technologies": [
    "Approximate nearest-neighbour search",
    "Determinism and numerical reproducibility",
    "Rust",
    "CUDA C++",
    "CBOR"
   ],
   "stats": [
    {
     "value": "100K",
     "label": "rows, the default cap on the training sample"
    },
    {
     "value": "4,096",
     "label": "cells at most; a configuration outside the bounds is refused"
    },
    {
     "value": "32",
     "label": "vectors at least in every cell"
    }
   ],
   "lede": "An approximate index trades exactness for speed, and most implementations trade reproducibility away with it: random seeds from the clock, training samples that depend on traversal order, floating-point reductions whose result depends on which thread finished first. When such an index returns different neighbours after a rebuild, nobody can say whether the data changed, the build changed, or something broke. design <blockquote class=\"dv-quote\" <p I wanted an index whose receipt is enough to rebuild it byte for byte.</p </blockquote Three hashes Every build produces three hashes. The configuration hash is over a canonical binary encoding of the parameters, so two builds with the same settings have the same hash regardless of how the settings were written. The training-set hash is",
   "quote": "I wanted an index whose receipt is enough to rebuild it byte for byte.",
   "evidence": [
    "Vector search and ANN indexes: an approximate index rebuilt byte for byte from a receipt of three hashes over its configuration, its training set and its artifact body.",
    "Deterministic GPU computation: k-means++ seeding split so the GPU computes distances and the host draws seeds, then 25 fixed Lloyd iterations in single precision with a fixed reduction order.",
    "Reproducible sampling: a reservoir sample seeded by a hash of the build seed and the sorted shard set, capped at 100K rows, so the same data in any order yields the same sample.",
    "Regression testing for ML indexes: builds repeated and shuffled with one artifact hash asserted, plus a recall floor of 85% at ten neighbours against exact search."
   ],
   "problem": "data-paths"
  },
  {
   "url": "https://coreyjames.ai/stories/the-database-decides-when-an-index-goes-stale/",
   "kind": "story",
   "title": "The database decides when an index goes stale",
   "subtitle": "Index invalidation moved into SQL triggers and load-time checks, so a stale index cannot be served, and partial builds are failed before the daemon accepts its first connection",
   "systems": [
    "inference-fabric",
    "postgresql-fabric"
   ],
   "technologies": [
    "PostgreSQL",
    "Approximate nearest-neighbour search",
    "Rust",
    "Idempotency, exactly-once effects and crash recovery"
   ],
   "stats": [
    {
     "value": "2",
     "label": "triggers in the database that mark an index stale"
    },
    {
     "value": "3",
     "label": "load-time checks, in order, before a file is trusted"
    }
   ],
   "lede": "An approximate index is a summary of the vectors it was built over. When those vectors change, the index is wrong, and a service that keeps serving it will return confident, stale neighbours with no error. The usual defence is a rule in the application: remember to rebuild. I put the rule in the database instead, where it cannot be forgotten, and backed it with checks at load time and at startup. Two triggers in the database Vectors live in append-only shards, each with a journal whose entry count advances on every append. A trigger on the catalog marks every active index that covers a shard as stale the moment that shard's journal count advances, with a reason attached. A",
   "quote": "The write that changes the data is the write that invalidates the index.",
   "evidence": [
    "Database-enforced invariants: index invalidation moved into PostgreSQL catalog triggers, so the write that changes vector data marks every covering index stale.",
    "Fail-closed artifact loading: 3 ordered checks before an index file is trusted, kernel version, configuration hash and artifact hash, each mismatch a refusal with its reason.",
    "Exactly-once delivery and crash recovery: partial index builds failed and their files removed before the daemon binds its listener, a sweep that is a no-op on a clean database.",
    "Vector search and ANN indexes: search that loads only an active, checked index for a shard set and falls back to the general index, so a stale index is never a candidate."
   ],
   "problem": "data-paths"
  },
  {
   "url": "https://coreyjames.ai/stories/rebuild-only-what-moved/",
   "kind": "story",
   "title": "Rebuild only what moved",
   "subtitle": "Column-scoped change capture, a rule that chooses a full or a delta rebuild from the size of the change and never from its age, and a segment merge whose output is byte-identical to a full rebuild",
   "systems": [
    "inference-fabric",
    "postgresql-fabric"
   ],
   "technologies": [
    "PostgreSQL",
    "Rust",
    "Large-scale GPU data pipelines",
    "Determinism and numerical reproducibility"
   ],
   "stats": [
    {
     "value": "4 M",
     "label": "rows of embeddings the GPU files are built from"
    },
    {
     "value": "2",
     "label": "paths, delta and full, that must write the same bytes"
    }
   ],
   "lede": "GPU workers read vectors from contiguous files on disk, built from the embedding columns of a relational database: one file of single-precision rows, one of identifiers, and for member vectors a table of offsets that maps each cluster to its range of rows. Rebuilding all of them because a few embeddings changed is a waste, and doing it on a schedule is worse, because age says nothing about whether an embedding is still correct. Capturing the change where it happens A trigger on each member table captures inserts and deletes, and captures an update only when the embedding column is different from its old value. Changes land in a pending table and are grouped into batches, so nothing is lost",
   "quote": "A delta build must produce exactly the file a full build would have produced, or the two paths diverge and every consumer has to care which one ran.",
   "evidence": [
    "Change data capture in PostgreSQL: triggers that capture inserts, deletes and embedding changes into a pending table in batches, so nothing is lost between builds.",
    "Incremental index builds: a delta rebuild that copies unchanged cluster byte ranges and rewrites only changed clusters, producing the same bytes as a full rebuild over 4 M rows.",
    "Database-side decision logic: a SQL function choosing none, delta or full rebuild from the size of the change, full past 100,000 pending rows or 10% of the table, with no age term.",
    "PostgreSQL performance tuning: the capture trigger's per-update function-call overhead identified, with its column-scoped fix stated as open rather than implied away."
   ],
   "problem": "data-paths"
  },
  {
   "url": "https://coreyjames.ai/stories/three-shards-that-move-together/",
   "kind": "story",
   "title": "Three shards that move together",
   "subtitle": "Cluster, member and phantom vector files are interdependent, so they activate together in one transaction or not at all, only after the files are confirmed on disk, with a single-active invariant the database enforces",
   "systems": [
    "inference-fabric",
    "postgresql-fabric"
   ],
   "technologies": [
    "PostgreSQL",
    "Rust",
    "Idempotency, exactly-once effects and crash recovery",
    "Large-scale GPU data pipelines"
   ],
   "stats": [
    {
     "value": "3",
     "label": "vector files that activate in one transaction or not at all"
    },
    {
     "value": "1",
     "label": "active generation per schema and kind, held by a unique index"
    },
    {
     "value": "2",
     "label": "generations kept so a rollback has somewhere to go"
    }
   ],
   "lede": "The GPU analytics in Where a cluster sits read three kinds of vector file: the cluster centroids, the members with their per-cluster offsets, and the phantom candidates. The member offsets index into the centroid file, and the phantoms are scored against both. A reader that saw a new centroid file beside an old member file would compute nonsense without an error. So the three files form a coupled set, and the set is the unit of activation. design <figure class=\"dv-figure\" aria-label=\"Member offsets point into the centroid file: matched generations agree, mixed generations do not\" <div class=\"dv-two\" <div <span class=\"eyebrow\" One generation</span <div style=\"display: grid; grid-template-columns: 5.5rem minmax(0, 1fr); gap: 0.45rem 0.7rem; align-items: center; margin-top: 0.8rem\" <span class=\"lbl\" Centroids</span <div style=\"display:",
   "quote": "A partial activation is impossible by construction rather than by convention.",
   "evidence": [
    "Transactional artifact management: 3 interdependent vector files activated together in one PostgreSQL transaction or not at all, with a unique index allowing 1 active generation per kind.",
    "Fail-closed artifact pipelines: generations checked on disk before activation, missing as a terminal status, and 2 generations kept so a rollback has somewhere to go.",
    "Deterministic data layout: file names carrying kind and generation, and row order fixed so two builds of the same data are the same bytes, each shard signed with a collision-resistant hash."
   ],
   "problem": "data-paths"
  },
  {
   "url": "https://coreyjames.ai/stories/storage-that-refuses-to-become-a-coordinator/",
   "kind": "story",
   "title": "Storage that refuses to become a coordinator",
   "subtitle": "A tensor store that appends, returns a stable address and knows nothing about its consumers; the coordinator tables it once had were removed and the boundary is enforced by checks in the build",
   "systems": [
    "inference-fabric"
   ],
   "technologies": [
    "Append-only log and journal design",
    "Rust",
    "Binary wire protocol design",
    "Idempotency, exactly-once effects and crash recovery"
   ],
   "stats": [
    {
     "value": "4",
     "label": "refusals the build checks for in the source"
    },
    {
     "value": "~800",
     "label": "lines of acceptance test holding the contract"
    }
   ],
   "lede": "The vector store under my research pipeline receives tensors from the extraction engines and the embedders and hands back an address. For a while it also tracked which consumers had accepted which payloads, de-duplicated by content, and answered questions about consumer schemas, because each of those was convenient for someone. I took them out and wrote the boundary down. design <blockquote class=\"dv-quote\" <p Every one of them made the store a coordinator, and a coordinator is a single point of contention and a second source of truth.</p </blockquote What an append is A producer sends an envelope. The store parses the envelope, recomputes the content hash over the tensor bytes, and checks the envelope's characteristics against the current generation; any",
   "quote": "Every one of them made the store a coordinator, and a coordinator is a single point of contention and a second source of truth.",
   "evidence": [
    "Append-only log design: a tensor store that journals each append before payload and lineage and returns a stable address of generation, shard, row, offset and content hash.",
    "System boundary design: coordinator duties removed from a storage service, with 4 refusals enforced by build checks that fail if the forbidden patterns reappear.",
    "Exactly-once delivery and crash recovery: shards replayed and truncated to the last consistent journal entry before the listener binds, with torn tails counted in a metric.",
    "Backpressure and admission control: a high-water mark answering busy with a retry hint and a client circuit breaker with a half-open probe, held by an acceptance test of about 800 lines."
   ],
   "problem": "data-paths"
  },
  {
   "url": "https://coreyjames.ai/stories/the-queue-that-should-not-exist/",
   "kind": "story",
   "title": "The queue that should not exist",
   "subtitle": "I built an inference queue manager with two-stage backpressure and permit-carrying requests, then found the runtime already had a token-based queue, and reduced mine to a wrapper",
   "systems": [
    "inference-fabric"
   ],
   "technologies": [
    "Rust",
    "Capacity engineering, backpressure and load testing",
    "NVIDIA TensorRT-LLM",
    "Contract-first interface design"
   ],
   "stats": [
    {
     "value": "64",
     "label": "requests in flight at most, bounded by a channel"
    },
    {
     "value": "~1,200",
     "label": "lines in the wrapper that remains"
    },
    {
     "value": "1,600",
     "label": "lines in the token queue it almost duplicated"
    }
   ],
   "lede": "Between the services that need text generated and the engine that generates it, I built a queue manager. It was a good one. Then I read the runtime underneath it properly. design <figure class=\"dv-figure\" aria-label=\"The queue manager as built: permit-carrying requests in a bounded channel, with the permit released on every exit\" <div class=\"dv-two\" <div <span class=\"eyebrow\" In-flight channel · each request carries its permit</span <div class=\"dv-pages\" style=\"margin-top: 0.8rem\" aria-hidden=\"true\" <span class=\"dv-page\" style=\"width: 10px; height: 14px; background: var(--accent)\" </span <span class=\"dv-page\" style=\"width: 10px; height: 14px; background: var(--accent)\" </span <span class=\"dv-page\" style=\"width: 10px; height: 14px; background: var(--accent)\" </span <span class=\"dv-page\" style=\"width: 10px; height: 14px; background: var(--accent)\" </span <span class=\"dv-page\" style=\"width: 10px; height: 14px; background: var(--accent)\" </span <span class=\"dv-page\" style=\"width: 10px; height:",
   "quote": "Two layers of backpressure with different units would have fought each other, and the request-level one would have won by starving the token-level one of work.",
   "evidence": [
    "Backpressure design: a request-level queue with permit-carrying requests, at most 64 in flight and the permit released on every path, built and then reduced to a wrapper.",
    "Inference serving architecture: the runtime's lock-free token-capacity queue recognised as doing admission where the engine has its limits, and admission delegated to it.",
    "Software architecture simplification: a second backpressure layer in different units removed before it could starve the token queue; the wrapper is about 1,200 lines and the queue 1,600."
   ],
   "problem": "gpu-economics"
  },
  {
   "url": "https://coreyjames.ai/stories/a-doorbell-the-gpu-waits-on/",
   "kind": "story",
   "title": "A doorbell the GPU waits on",
   "subtitle": "Batches cross from the CPU to the GPU through a pinned ring and a 64-byte doorbell the GPU's stream waits on directly, with no CPU synchronisation; and why that path is used for the extraction engines and left off for the vendor's executor",
   "systems": [
    "inference-fabric"
   ],
   "technologies": [
    "CUDA Driver API",
    "GPU memory management",
    "C++",
    "Rust",
    "Binary wire protocol design"
   ],
   "stats": [
    {
     "value": "1 : 1",
     "label": "one producer, the filler thread; one consumer, the decode thread"
    },
    {
     "value": "10",
     "label": "retries of 1 ms on a full ring, then a block; a batch is never dropped"
    },
    {
     "value": "0",
     "label": "host threads between a publish and the GPU starting work"
    }
   ],
   "lede": "The batch filler writes a batch into memory the GPU can read directly, and the GPU's stream begins work the instant the batch is published, without a host thread noticing and launching anything. The CUDA driver has a primitive for exactly this, a stream operation that blocks until a 64-bit value in memory reaches a threshold, and the runtime's hot queue is built around it. design <blockquote class=\"dv-quote\" <p The fastest handoff from a CPU producer to a GPU consumer is one in which neither side waits on the other's clock.</p </blockquote The ring and the bell Batches live in a ring of pinned host memory, mapped for direct GPU access and write-combined for fast CPU writes, with pages pre-faulted",
   "quote": "The fastest handoff from a CPU producer to a GPU consumer is one in which neither side waits on the other's clock.",
   "evidence": [
    "CUDA driver programming: a stream operation that waits on a 64-byte doorbell in mapped pinned memory, so the GPU starts a batch with no host thread in the loop.",
    "Lock-free and zero-copy data paths: a single-producer single-consumer pinned ring of write-combined, pre-faulted pages that pads at the wrap and never drops a batch, 10 bounded retries then a block.",
    "GPU memory management: the pinned path enabled for a device-reading extraction backend and kept off for a CPU-reading executor, with a counter that fires on a mismatch."
   ],
   "problem": "gpu-economics"
  },
  {
   "url": "https://coreyjames.ai/stories/every-request-accounted-for/",
   "kind": "story",
   "title": "Every request accounted for",
   "subtitle": "The tool-discovery model's fleet daemon has a nine-point service contract: 512 requests offered to 64 clients with a queue of sixteen gave 244 answered, 268 refused with a typed reason and none dropped, and a shutdown that answered every request in flight",
   "systems": [
    "capabilities-model"
   ],
   "technologies": [
    "Rust",
    "CUDA C++",
    "Capacity engineering, backpressure and load testing",
    "Unix domain sockets",
    "Model Context Protocol (MCP)"
   ],
   "stats": [
    {
     "value": "244",
     "label": "answered, of 512 requests offered by 64 clients to a queue of sixteen"
    },
    {
     "value": "268",
     "label": "refused with a typed busy reason"
    },
    {
     "value": "8 of 8",
     "label": "requests in flight answered when the daemon was terminated"
    }
   ],
   "lede": "The tool-discovery model answers one question, which tool does this request need, for every agent in my estate, and it does so from a GPU it shares with a larger serving model. A router beside a production model tells how it fits in the memory it is allowed. This is how it serves: a daemon whose contract says what happens to every request it is offered, including the ones it refuses. Two daemons The serial daemon runs one thread per connection over a Unix socket and holds the engine behind a single mutex. Decode is batch-one there, so the mutex is the queue and nothing more is needed. The fleet daemon is the serving shape: connection threads feed a bounded",
   "quote": "A refusal before bind means no client ever saw a half-ready service.",
   "evidence": [
    "Service contracts for inference daemons: a nine-point contract under which 512 requests offered by 64 clients to a queue of sixteen gave 244 answered and 268 refused with a typed reason.",
    "Backpressure and load shedding: a bounded queue in which every refusal carries a typed busy reason and no request is dropped.",
    "Graceful shutdown: 8 of 8 requests in flight answered when the daemon was terminated.",
    "Continuous batching: one engine thread stepping rows from every sequence in flight, each in its own paged cache, so a short answer never waits for a long one.",
    "MCP server design: the daemon reachable as a standard tool-protocol server over standard input and over streamable HTTP with TLS."
   ],
   "problem": "small-models"
  },
  {
   "url": "https://coreyjames.ai/stories/the-recovery-that-drained-the-card/",
   "kind": "story",
   "title": "The recovery that drained the card",
   "subtitle": "Four failed engine loads took a shared GPU from 1,801 MiB free to 2, because partial allocations were never released; the fix made creation crash-safe and made the admission arithmetic match the allocation it predicts",
   "systems": [
    "capabilities-model"
   ],
   "technologies": [
    "CUDA Driver API",
    "GPU memory management",
    "CUDA C++",
    "Rust",
    "GPU admission control and co-residency"
   ],
   "stats": [
    {
     "value": "4",
     "label": "failed engine loads in a row, each one passing admission"
    },
    {
     "value": "~503 MiB",
     "label": "the CUDA context the admission arithmetic had left out"
    },
    {
     "value": "2,740",
     "label": "MiB, the engine's whole allowance beside a 30B serving model"
    }
   ],
   "lede": "The tool-discovery engine lives on a GPU beside a 30-billion-parameter serving model, in a fixed allowance and no more. An admission check compares the engine's requirement with the card's free memory before anything is allocated, and refuses with the shortfall if it does not fit. That check once passed every time while the engine failed to load every time, and the card drained. What went wrong Engine creation allocated its buffers in sequence, and when a later allocation failed, the earlier ones were not freed before the error returned. Each retry therefore started with less free memory than the last, passed admission because the arithmetic looked only at the engine's own total, and failed further along. A larger serving model",
   "quote": "A failed load leaves the card as it found it.",
   "evidence": [
    "GPU memory management: engine creation made crash-safe after four failed loads took a shared GPU from 1,801 MiB free to 2.",
    "Admission control for GPU memory: admission arithmetic made to mirror the allocator, including the ~503 MiB CUDA context it had left out.",
    "Incident root-cause analysis: four failed loads, each passing admission, traced to partial allocations never released and a context missing from the arithmetic.",
    "Inference serving on shared GPUs: an engine held to a 2,740 MiB allowance beside a 30B serving model, with cache pages reserved per request before admission."
   ],
   "problem": "gpu-economics"
  },
  {
   "url": "https://coreyjames.ai/stories/prove-the-mechanism-before-the-model/",
   "kind": "story",
   "title": "Prove the mechanism before the model",
   "subtitle": "Three load-bearing ideas behind the custom decoder, a device-side graph loop, a persisting L2 window and a constant-memory trie mask, were each proved on the real GPU in a small lab before the model existed, and one of them contradicted the documentation",
   "systems": [
    "capabilities-model"
   ],
   "technologies": [
    "CUDA C++",
    "CUDA Driver API",
    "Performance engineering and benchmarking",
    "GPU numerical kernel design"
   ],
   "stats": [
    {
     "value": "4.304 µs",
     "label": "saved per token per kernel by looping on the device"
    },
    {
     "value": "60 MiB",
     "label": "of the 96 MiB L2, the set-aside ceiling measured on the card"
    },
    {
     "value": "0.016 µs",
     "label": "to consult the constant-memory mask at a 131,072-token vocabulary"
    }
   ],
   "lede": "The custom decoder for the tool-discovery model, told in Constraint made cheaper than no constraint, rests on three mechanisms that the whole design assumes will work: a decode loop that runs on the device under a graph whose continuation predicate the GPU itself writes, a window of L2 cache set aside so the model's weights stay resident between tokens, and a trie-shaped grammar mask served from constant memory. If any of the three had not worked on the generation of GPU I had, the decoder would have been built on sand. So before the model was trained, each was built and measured on its own, on the real card, with a toy body. design <figure class=\"dv-figure\" aria-label=\"Three mechanisms proved in",
   "quote": "The decoder was then built on three numbers rather than three hopes.",
   "evidence": [
    "Hardware-first prototyping: three decoder mechanisms each proved on the real GPU in a small lab with a toy body before the model was trained.",
    "CUDA graphs and device-side control flow: a decode loop under a graph with a conditional node, 4.304 µs saved per token per kernel.",
    "GPU cache tuning: an L2 persisting window whose set-aside ceiling measured 60 MiB of the 96 MiB L2, against what the documentation suggests.",
    "Constant-memory kernel design: a grammar mask consulted in 0.016 µs at a 131,072-token vocabulary."
   ],
   "problem": "gpu-economics"
  },
  {
   "url": "https://coreyjames.ai/stories/reading-a-file-format-by-correlation/",
   "kind": "story",
   "title": "Reading a file format by correlation",
   "subtitle": "The four-bit weight format's layout was established by correlating candidate decodings against the known weights before a kernel was written, 0.9955 against 0.0018, and four-bit was positioned as a footprint win rather than a speed win",
   "systems": [
    "capabilities-model"
   ],
   "technologies": [
    "CUDA C++",
    "Model quantization",
    "Determinism and numerical reproducibility",
    "ML evaluation methodology"
   ],
   "stats": [
    {
     "value": "256",
     "label": "byte patterns, every one, on which the hardware and table eight-bit paths agree"
    },
    {
     "value": "2, 4, 8",
     "label": "rows per block in the tiled kernels, each bit-identical to the untiled form"
    },
    {
     "value": "2.53×",
     "label": "denser in memory with four-bit weights, and no faster"
    }
   ],
   "lede": "The tool-discovery model ships in several precisions, and the smallest is a four-bit floating-point format with a block scale: a nibble per weight holding a two-bit exponent and a one-bit mantissa, and an eight-bit scale per block of weights. The format's documentation describes the arithmetic. It does not pin down, byte by byte, which nibble is which weight and how the block scales are laid out against them, and a kernel written against the wrong layout decodes plausible nonsense. design <figure class=\"dv-figure\" aria-label=\"One block of the four-bit format: a scale byte and a nibble per weight\" <span class=\"eyebrow\" One block of the four-bit format</span <div style=\"display: flex; gap: 10px; align-items: center; margin-top: 0.6rem; flex-wrap: wrap\" aria-hidden=\"true\" <span class=\"dv-page\" style=\"width: 40px;",
   "quote": "The four-bit build is the footprint build, the eight-bit build is the serving build.",
   "evidence": [
    "Reverse engineering of binary formats: a four-bit weight layout established by correlating candidate decodings with known weights, 0.9955 against 0.0018, before a kernel was written.",
    "Low-precision kernel development: four-bit kernels decoding through constant-memory lookup tables, and eight-bit hardware and table paths shown to agree on all 256 byte patterns.",
    "LLM quantization trade-offs: four-bit weights positioned as a footprint win, 2.53 times denser in memory and no faster.",
    "Kernel equivalence testing: register-tiled row kernels at 2, 4 and 8 rows per block, each bit-identical to the untiled form."
   ],
   "problem": "gpu-economics"
  },
  {
   "url": "https://coreyjames.ai/stories/fast-transcripts-that-were-wrong/",
   "kind": "story",
   "title": "Fast transcripts that were wrong",
   "subtitle": "GPU speech recognition that was far faster than the CPU path and quietly dropped sentences, and the correctness gate every GPU integration in the voice engine now passes",
   "systems": [
    "helix"
   ],
   "technologies": [
    "Speech recognition model",
    "Real-time audio pipeline engineering",
    "NVIDIA Blackwell GPUs",
    "Docker",
    "ML evaluation methodology"
   ],
   "stats": [
    {
     "value": "25×",
     "label": "faster than the CPU path at best on the GPU, 18× at worst"
    },
    {
     "value": "4",
     "label": "workarounds in the tensor library, none of which held"
    }
   ],
   "lede": "The voice engine recognises speech one utterance at a time: the voice-activity detector decides where a turn ends, and the whole turn goes to the recogniser in one call. On the CPU that call had a floor of about a second, because the recogniser pads every input to a thirty-second window before it listens. A second of dead air after every sentence is the difference between a colleague and a voicemail, so the recogniser moved to a server on a Blackwell GPU, and turns came back in 38 to 74 milliseconds. design <figure class=\"dv-figure\" aria-label=\"One recogniser turn on each path\" <span class=\"eyebrow\" One turn, by path · in the order the engine tries them</span <div class=\"dv-bars\" <span Native GPU server</span",
   "quote": "A system can be fast and green and wrong.",
   "evidence": [
    "Speech recognition pipelines on GPUs: recognition 18 to 25 times faster than the CPU path, with a fallback runtime at 235 ms per turn.",
    "ML output correctness testing: a fixture comparing a known recording with its known transcript, added after a fast GPU path silently dropped whole sentences.",
    "Root-cause analysis on new GPU toolchains: 4 workarounds in the tensor library failed and a one-line base-image change brought the dropped sentences back."
   ],
   "problem": "voice"
  },
  {
   "url": "https://coreyjames.ai/stories/from-two-seconds-to-under-one/",
   "kind": "story",
   "title": "From two seconds to under one",
   "subtitle": "Question to first sound, taken apart stage by stage: the silence window, recognition, reasoning, the first spoken sentence and synthesis, each cut named and each benchmark row carrying its own definition",
   "systems": [
    "helix"
   ],
   "technologies": [
    "Real-time audio pipeline engineering",
    "Conversational turn-taking and barge-in",
    "Speech recognition model",
    "Performance engineering and benchmarking"
   ],
   "stats": [
    {
     "value": "400 ms",
     "label": "cut at most on complex answers by keeping the first sentence short, 300 at least"
    },
    {
     "value": "5,668",
     "label": "turns in a ten-minute loopback soak, every one processed"
    },
    {
     "value": "96 KB",
     "label": "memory growth across that soak"
    }
   ],
   "lede": "A spoken assistant is judged by one interval: the gap between the moment a person stops talking and the moment they hear a reply begin. In the voice engine's first working version that gap was more than twice what it is now. The stages Before the work, the chain was roughly: 700 milliseconds of silence before the engine decided the person had finished, about a second for speech recognition on the CPU, a few tens of milliseconds for the reasoning model's first words, and about 310 milliseconds for the synthesiser's first frame of audio, with the first sentence having to complete before it could be spoken. The silence window went from 700 milliseconds to 500, after an earlier fix had",
   "quote": "Nothing about the reply got shorter. The gap was taken apart into its stages.",
   "evidence": [
    "Latency engineering for voice AI: question to first sound taken apart stage by stage and cut from about two seconds to under one.",
    "Response shaping for voice: keeping the first spoken sentence short cut 300 to 400 ms on complex answers.",
    "Soak testing and memory stability: 5,668 turns in a ten-minute loopback soak, every one processed, with 96 KB of memory growth.",
    "Performance benchmarking methodology: every figure in the benchmark file tied to its own row and definition, from which event to which, warm or cold."
   ],
   "problem": "voice"
  },
  {
   "url": "https://coreyjames.ai/stories/building-the-streaming-my-speech-model-did-not-ship/",
   "kind": "story",
   "title": "Building the streaming my speech model did not ship",
   "subtitle": "The open-weight voice model I chose had no streaming hook, so I ported its token loop, decoded its audio in chunks and pinned its diffusion noise so the joins are seamless",
   "systems": [
    "helix"
   ],
   "technologies": [
    "Neural speech synthesis",
    "Real-time audio pipeline engineering",
    "Python",
    "PyTorch",
    "NVIDIA Blackwell GPUs"
   ],
   "stats": [
    {
     "value": "8",
     "label": "synthesisers in the bake-off"
    },
    {
     "value": "12",
     "label": "tokens before the first chunk is released"
    },
    {
     "value": "56",
     "label": "voices registered, each persona with its own"
    }
   ],
   "lede": "The voice model was chosen in a bake-off on the criteria that matter in a conversation: time to first audio, real-time factor, memory, licence, voice cloning and streaming. The winner carried a permissive licence. design <figure class=\"dv-figure\" aria-label=\"Bake-off winner against the runner-up\" <div class=\"dv-two\" <div <span class=\"eyebrow\" Real-time factor · lower is faster</span <div class=\"dv-bars\" <span Winner</span <span <span class=\"bar on\" style=\"width: 63%\" </span </span <span class=\"v on\" 0.27</span <span Runner-up</span <span <span class=\"bar\" style=\"width: 100%\" </span </span <span class=\"v\" 0.35–0.43</span </div </div <div <span class=\"eyebrow\" GPU memory</span <div class=\"dv-bars\" <span Winner</span <span <span class=\"bar on\" style=\"width: 40%\" </span </span <span class=\"v on\" 6–8 GB</span <span Runner-up</span <span <span class=\"bar\" style=\"width: 100%\" </span </span <span class=\"v\" ≈20 GB</span </div </div",
   "quote": "A small patch over the sampler is the difference between streaming that works and streaming that crackles.",
   "evidence": [
    "Speech synthesis engineering: streaming built for an open-weight voice model that had none, cutting time to first audio to about 0.3 s from about 1.6.",
    "Model evaluation and selection: 8 synthesisers compared on time to first audio, real-time factor, memory, licence, voice cloning and streaming.",
    "Diffusion sampling control: noise pinned across chunk overlaps so every join renders identically and streams without clicks, first chunk after 12 tokens.",
    "Responsible voice AI: 56 registered voices under a rule never to clone a real human voice without documented consent."
   ],
   "problem": "voice"
  },
  {
   "url": "https://coreyjames.ai/stories/three-hundred-milliseconds-of-hello/",
   "kind": "story",
   "title": "Three hundred milliseconds of hello",
   "subtitle": "The lines an assistant says most, the greeting, the thinking fillers, the short acknowledgements, are pre-rendered per voice at session start and play in under a millisecond, through the same cancellation path as synthesised speech",
   "systems": [
    "helix"
   ],
   "technologies": [
    "Neural speech synthesis",
    "Real-time audio pipeline engineering",
    "Rust"
   ],
   "stats": [
    {
     "value": "≈8 s",
     "label": "added to session boot to fill the cache"
    },
    {
     "value": "5.3 s",
     "label": "to condition a voice the first time, nothing after"
    },
    {
     "value": "8",
     "label": "voices held in the bounded conditioning cache"
    }
   ],
   "lede": "The streaming synthesiser in Building the streaming my speech model did not ship produces its first frame of audio about 300 milliseconds after it is given a sentence, and that figure is flat: eleven characters or two hundred and thirty, the first frame costs the same. For a long answer it is a fine price. For \"Hello\", \"One moment\" and \"Let me check\", which a voice assistant says many times an hour, it is a tax on the words that most need to be instant. design <figure class=\"dv-figure\" aria-label=\"The synthesiser's first frame does not depend on sentence length\" <div class=\"dv-two\" <div <span class=\"eyebrow\" Sentence length · characters</span <div class=\"dv-bars\" <span \"Hello\"-sized</span <span <span class=\"bar\" style=\"width: 5%\" </span </span <span class=\"v\"",
   "quote": "Cached audio has to obey every rule synthesised audio obeys.",
   "evidence": [
    "Latency engineering for voice AI: the lines an assistant says most pre-rendered per voice at session start, so they skip the roughly 300 ms a synthesiser takes to its first frame.",
    "Caching design for real-time audio: cached audio held to every rule synthesised audio obeys, filled by about 8 s added to session boot.",
    "Bounded caches: voice conditioning cached for 8 voices, 5.3 s the first time and nothing after."
   ],
   "problem": "voice"
  },
  {
   "url": "https://coreyjames.ai/stories/saying-numbers-out-loud/",
   "kind": "story",
   "title": "Saying numbers out loud",
   "subtitle": "A chemical formula came out as a sneeze and a thousand as ten thousand; a speech contract and a deterministic scrubber give the voice speakable text while the screen keeps the written answer",
   "systems": [
    "helix"
   ],
   "technologies": [
    "Neural speech synthesis",
    "Rust",
    "Conversational turn-taking and barge-in"
   ],
   "stats": [
    {
     "value": "≈800",
     "label": "lines in the deterministic scrubber"
    },
    {
     "value": "500",
     "label": "character ceiling on any clause, set by the synthesiser's own limits"
    }
   ],
   "lede": "A reasoning model writes for a screen. It writes \"H₂O\", \"8.832\", \"abcdef.md\", \"U.S.\" and \"1000\", and every one of those is a trap for a synthesiser that speaks phonemes. In real use the formula for water came out as a sneeze, a thousand was spoken as ten thousand, a filename was read as a word, and the abbreviation for the country became \"u dot s\". Each is small. Together they are the difference between an assistant that sounds like a colleague and one that sounds like a machine reading a document. Two layers The first layer is a speech contract in the prompt. The model follows it most of the time, and most of the time is not enough for",
   "quote": "I pair a contract the model is asked to follow with a deterministic layer that does not rely on it following.",
   "evidence": [
    "Speech synthesis pipelines: two layers between the model and the speaker, a prompt contract and a deterministic scrubber of about 800 lines on every clause.",
    "Text normalisation for TTS: formulas, large numbers, paths and abbreviations rewritten only for the voice, while subtitles and history keep what the model wrote.",
    "Property-based testing: every clause split checked to land on sentence-ending punctuation, under a 500-character ceiling."
   ],
   "problem": "voice"
  },
  {
   "url": "https://coreyjames.ai/stories/interruptions-that-only-people-can-make/",
   "kind": "story",
   "title": "Interruptions that only people can make",
   "subtitle": "Echo sounded like a person to the detector; the rules were set so a person always wins the floor, the agent's own voice never does, the first word of an interruption is heard, and a false stop re-speaks instead of going quiet",
   "systems": [
    "helix"
   ],
   "technologies": [
    "Conversational turn-taking and barge-in",
    "Real-time audio pipeline engineering",
    "Rust"
   ],
   "stats": [
    {
     "value": "18",
     "label": "attack cases in an adversarial review before anyone heard the feature"
    },
    {
     "value": "1",
     "label": "device period of audio, at most, left after a flush"
    },
    {
     "value": "0 s",
     "label": "of dead air after a false stop: the answer is spoken again"
    }
   ],
   "lede": "A voice assistant that cannot be interrupted is a lecture. One that can be interrupted by its own echo is worse, because it stops mid-sentence for nobody. The voice engine runs full duplex, listening while it speaks, and the design problem is to make a person's interruption instant and everything else inert. What stops the agent While the agent is listening, it starts a turn the moment speech begins. While it is speaking, it is harder to stop: an interruption has to be sustained speech with a confidence the detector measures, because residual echo and room noise come back as brief, low-confidence bursts and a person does not. The threshold was set from measurement: in real sessions the agent's own",
   "quote": "The agent's own voice can never take the floor from a person.",
   "evidence": [
    "Barge-in and turn-taking for voice AI: a person can always take the floor, while the agent's own echo and other AI voices cannot.",
    "Adversarial review of AI features: 18 attack cases reviewed before anyone heard the interruption feature.",
    "Real-time audio cancellation: one confirmed interruption cancels reasoning, synthesis, the speaker queue and the Teams call together.",
    "Recovery from false positives: a stop nobody made leaves 0 s of dead air, because the killed answer is spoken again word for word."
   ],
   "problem": "voice"
  },
  {
   "url": "https://coreyjames.ai/stories/listen-only-to-me/",
   "kind": "story",
   "title": "Listen only to me",
   "subtitle": "An opt-in filter for a desk microphone that hears its operator and not the television, enrolled without keeping a recording, switched by asking, and deliberately not used on Teams, with the reasons written down",
   "systems": [
    "helix"
   ],
   "technologies": [
    "Real-time audio pipeline engineering",
    "Rust",
    "Applied cryptography",
    "Conversational turn-taking and barge-in"
   ],
   "stats": [
    {
     "value": "8 × 8 s",
     "label": "guided enrolment samples, none of them kept"
    },
    {
     "value": "3",
     "label": "policies: open, shadow and locked"
    }
   ],
   "lede": "A desk microphone hears everything in the room: the operator, a visitor, the television, loud typing. An assistant that can take actions on a spoken word should know whose word it is. The voice engine has an optional voiceprint filter that recognises the operator's voice and silences every other voice before the engine can hear it, so another speaker cannot interrupt the agent, be transcribed, or trigger a tool. Enrolment without a recording Enrolment covers the ways a person actually sits at a desk, through the same echo cancellation and denoising the engine applies to speech, so the profile matches what the engine will hear. design <figure class=\"dv-figure\" aria-label=\"Enrolment keeps an embedding and no recording\" <span class=\"eyebrow\" Eight guided samples",
   "quote": "The cost of silencing the operator is higher than the cost of admitting a doubtful burst.",
   "evidence": [
    "Speaker verification for voice AI: an opt-in voiceprint filter that hears its operator and silences other voices, enrolled from 8 guided samples with no recording kept.",
    "Privacy-preserving design: enrolment keeps an embedding and discards the audio, and the profile is written atomically and readable by the operator alone.",
    "Voice-controlled policy: 3 filter policies switched by asking, with a locked filter failing loudly when its profile is missing."
   ],
   "problem": "voice"
  },
  {
   "url": "https://coreyjames.ai/stories/one-percent-network-seventy-eight-percent-gpu/",
   "kind": "story",
   "title": "One percent network, seventy-eight percent GPU",
   "subtitle": "A slow Teams turn was blamed on the cloud hop; measurement showed the network was about one percent of it and a speech GPU shared with an embedding service was most of the rest, so the compute moved and the cloud stayed",
   "systems": [
    "helix"
   ],
   "technologies": [
    "Performance engineering and benchmarking",
    "Microsoft real-time media SDK",
    "Real-time audio pipeline engineering",
    "GPU admission control and co-residency"
   ],
   "stats": [
    {
     "value": "65 ms",
     "label": "round trip between the cloud bridge and the home lab"
    },
    {
     "value": "1.317 s",
     "label": "end of speech to first reply audio on a responsive Teams turn"
    },
    {
     "value": "100%",
     "label": "speech GPU utilisation at peak in the slow window, never below 95"
    },
    {
     "value": "5,859",
     "label": "frames validated in a closed-loop call, zero rejects"
    }
   ],
   "lede": "The Teams voice path crosses a cloud: audio leaves Microsoft's media platform, reaches a Windows bridge on an Azure virtual machine, and crosses an authenticated WebSocket to the voice engine on my own hardware, then back. When a Teams turn took about six seconds from the end of a question to the first sound of the answer, the cloud hop was the obvious suspect. design <blockquote class=\"dv-quote\" <p The obvious suspect was wrong.</p </blockquote Measuring the transport The transport was measured on its own first. design <figure class=\"dv-figure\" aria-label=\"What the cloud hop costs\" <span class=\"eyebrow\" Milliseconds</span <div class=\"dv-bars\" <span WebSocket setup, once per session</span <span <span class=\"bar\" style=\"width: 79.9%\" </span </span <span class=\"v\" 165–218</span <span Session open</span <span <span class=\"bar\"",
   "quote": "The obvious suspect was wrong.",
   "evidence": [
    "Performance diagnosis: a slow Teams turn blamed on the cloud hop measured at about one percent network and about seventy-eight percent contended speech GPU.",
    "Latency measurement: per-stage timing of a Teams turn, recognition at 253 ms and synthesis at 4.847 s to first frame, before synthesis moved to a GPU of its own.",
    "Microsoft Teams real-time media: a cloud bridge carrying 91,643 buffers at 50.001 per second with zero stalls and a 65 ms round trip to the home lab.",
    "Closed-loop media validation: 5,859 frames validated in a closed-loop call with zero rejects."
   ],
   "problem": "voice"
  },
  {
   "url": "https://coreyjames.ai/stories/a-tool-catalogue-bigger-than-the-model/",
   "kind": "story",
   "title": "A tool catalogue bigger than the model",
   "subtitle": "Why a voice assistant played its opener and then fell silent, the two-stage fix I rolled back, and the boundary that replaced it",
   "systems": [
    "helix",
    "fafohive"
   ],
   "technologies": [
    "Model Context Protocol (MCP)",
    "MCP tool design",
    "Rust",
    "Context engineering and persistent agent memory"
   ],
   "stats": [
    {
     "value": "88",
     "label": "remote tools offered to the voice brain"
    },
    {
     "value": "300",
     "label": "provider operations kept out of voice by configuration"
    }
   ],
   "lede": "The voice engine reaches the world through tools: native ones for assigning work, saving and searching memory, and setting the voiceprint policy, and remote ones over the tool protocol, including the meeting-action server that lets it join a Teams meeting, raise a hand or put a deck on screen. One day the assistant began speaking its short opener and then falling silent where the full answer should have been. The arithmetic The tool list alone was larger than the model's entire 32,768-token window, so every full request was refused by the serving layer, while the tool-free opener sailed through and made the failure look like a stall. design <figure class=\"dv-figure\" aria-label=\"What each lane carried\" <div style=\"position: relative; display: grid; grid-template-columns:",
   "quote": "It worked and it was unusable.",
   "evidence": [
    "MCP tool design: diagnosed a voice assistant that fell silent because its tool list was larger than the model's 32,768-token window.",
    "Context budgeting for small models: tools scoped to each surface, keeping 300 provider operations out of voice while 88 remote tools stay available.",
    "Robust tool calling: tool arguments repaired when a small model misnames keys, with idempotent receipts so a spoken retry never runs work twice."
   ],
   "problem": "small-models"
  },
  {
   "url": "https://coreyjames.ai/stories/a-proof-that-proved-nothing/",
   "kind": "story",
   "title": "A proof that proved nothing",
   "subtitle": "An echo-cancellation score looked excellent until an unrelated reference scored higher; the rebuilt proof uses a negative control, and the same discipline runs through the voice engine's tests",
   "systems": [
    "helix"
   ],
   "technologies": [
    "Real-time audio pipeline engineering",
    "ML evaluation methodology",
    "Rust",
    "Determinism and numerical reproducibility"
   ],
   "stats": [
    {
     "value": "5 of 5",
     "label": "content words recovered from synthesised speech"
    },
    {
     "value": "0",
     "label": "for a pure tone, which came back as a description of music"
    },
    {
     "value": "2",
     "label": "layers of echo cancellation, the engine and the desk device"
    }
   ],
   "lede": "The voice engine cancels its own echo with the WebRTC AEC3 algorithm, fed the engine's own playback as the reference, in ten-millisecond blocks, with the delay seeded from the device clocks. The first proof that it worked reported an echo return loss enhancement of 36.8 decibels on an echo-only recording, which is an excellent number. Then the same test was run with an uncorrelated reference, audio that had nothing to do with the echo, and it scored 37.8. What the number was measuring The canceller has a suppressor stage that gates low-level signal, and on an echo-only recording the suppressor was doing all the work: whatever the reference, it attenuated the echo because the echo was all there was. The",
   "quote": "A proof that passes with the wrong input is a proof of the test harness.",
   "evidence": [
    "ML evaluation methodology: an echo-cancellation score of 36.8 thrown out after an unrelated reference scored 37.8; the proof was rebuilt around a negative control.",
    "Echo cancellation engineering: AEC3 fed the engine's own playback as its reference in ten-millisecond blocks, tested under double-talk.",
    "Speech pipeline testing: synthesised speech recovering 5 of 5 content words, with a pure tone coming back as 0."
   ],
   "problem": "proof"
  },
  {
   "url": "https://coreyjames.ai/systems/activekv/",
   "kind": "system",
   "title": "ActiveKV",
   "subtitle": "An inference-memory layer for vLLM: the conversation's history in host RAM, the GPU as a bounded working set",
   "systems": [],
   "technologies": [
    "C++",
    "SYCL / oneAPI",
    "vLLM",
    "PyTorch XPU",
    "pybind11",
    "GPU memory management",
    "KV-cache engineering",
    "Intel Arc GPUs",
    "Numerical reproducibility"
   ],
   "stats": [
    {
     "value": "13 of 13",
     "label": "exact cells bit-identical to fully resident attention at the port, 12 of 12 hybrid"
    },
    {
     "value": "1 of 867",
     "label": "former Python dispatch sites still in Python, kept by a cited framework contract"
    },
    {
     "value": "12–22%",
     "label": "lower time to first token than stock vLLM, single request, every context length"
    },
    {
     "value": "20%",
     "label": "faster cold 32K-token prefill from the Xe2 kernel patches"
    }
   ],
   "lede": "Every serving engine I have worked with assumes a model's working memory lives on the GPU. That assumption is why a 32 GB card decides how much context a model can hold. I decided to remove it. ActiveKV is an inference-memory layer I architected for vLLM: the conversation's attention history lives in pinned host RAM, and the GPU keeps a bounded, budgeted working set. On one Intel Arc Pro GPU, a 27-billion-parameter model serves 128,000-token histories. On a single 8,000-token request it beats stock vLLM on time to first token, inter-token latency and throughput. The runtime is C++ throughout, ported from a Python prototype without changing an output bit, and it is delivered as compiled binaries plus a patch to",
   "quote": "Context length should be a host-memory budget, and it should stop being a hardware limit.",
   "evidence": [
    "KV-cache offload for LLM inference: attention history in host RAM with the GPU as a bounded working set, on one Intel Arc Pro GPU with 32 GB.",
    "C++ and native ports with parity proof: a Python runtime ported to C++ with 13 of 13 exact cells bit-identical and 1 of 867 dispatch sites left in Python under a cited contract.",
    "Inference serving architecture: 12-22% lower time to first token than stock vLLM on a single request at every context length.",
    "Intel GPU and SYCL/oneAPI engineering: kernel patches on Xe2 for 20% faster cold 32K-token prefill, each gated on identical outputs.",
    "vLLM internals: delivered as compiled binaries plus a patch to the user's own vLLM, with no Python of mine in the release payload.",
    "Observability and instrumentation: per-token tracing from scheduler to device to client at selectable levels, with its own overhead measured."
   ]
  },
  {
   "url": "https://coreyjames.ai/systems/agent-swarm/",
   "kind": "system",
   "title": "Agent Swarm",
   "subtitle": "A self-hosted, multi-host runtime where tools are the platform and agents are compositions",
   "systems": [],
   "technologies": [
    "Rust",
    "Tokio",
    "Docker",
    "Redis Streams",
    "PostgreSQL",
    "YAML tool definitions",
    "Signed message envelopes",
    "Open-source models on vLLM"
   ],
   "stats": [
    {
     "value": "12",
     "label": "steps every tool call passes through, in a frozen order"
    },
    {
     "value": "40",
     "label": "declarative tools, none without golden and attack fixtures"
    },
    {
     "value": "0",
     "label": "commits to the main repository across three coding-agent runs on a local model"
    },
    {
     "value": "60+",
     "label": "locked decisions in a 2,000-line master plan"
    }
   ],
   "lede": "Every new agent an organisation adds tends to arrive with its own tooling, its own permissions and its own messaging, and every one of those is a new place for something to go wrong. I wanted to build the safety machinery once, make it the only path, and make adding an agent a matter of declaring one. Agent Swarm is that runtime. Tools are the platform: every action any agent takes passes through one frozen, tested pipeline. The runtime runs coding, analysis and service agents on local open-source models and on frontier models, spans more than one machine, and its persona library and container launcher start the seats of my governance platform. The idea Validation, authorisation, rate limits, quotas, retries,",
   "quote": "I froze the pipeline order. Less flexibility, and exactly one way an action happens.",
   "evidence": [
    "Agent orchestration: a self-hosted multi-host agent runtime where every tool call passes one frozen pipeline of 12 steps, and a new agent persona is a declaration.",
    "Test-gated tool catalogs: 40 declarative tools, none without golden and attack fixtures, with 50 golden fixtures in the catalog and hash-pinned catalogs checked for drift on every host.",
    "Sandboxing and container hardening: a persona launcher of about 23,000 lines starting sandboxed containers with scoped tokens, workspaces and budgets; secrets released per action and never written to disk.",
    "Distributed agent messaging: signed agent-to-agent envelopes with chain-depth checks, checked locally for sub-millisecond peer authorisation, and heartbeats that reclaim work from a silent agent.",
    "Least-privilege design for autonomous coding agents: 0 commits to the main repository across three coding-agent runs on a local model.",
    "Architecture under written decisions: 60+ locked decisions in a 2,000-line master plan, and a carve gate that keeps product crates free of estate-specific imports."
   ]
  },
  {
   "url": "https://coreyjames.ai/systems/agentos/",
   "kind": "system",
   "title": "AgentOS",
   "subtitle": "A governed work-order control plane for teams of AI engineering agents",
   "systems": [],
   "technologies": [
    "Rust",
    "PostgreSQL",
    "JSON Schema",
    "Model Context Protocol (MCP)",
    "Agent hook systems",
    "Multi-agent system architecture",
    "systemd"
   ],
   "stats": [
    {
     "value": "246",
     "label": "work orders governed, including the programs that built most of this site"
    },
    {
     "value": "106",
     "label": "hook modules across eleven lifecycle events, each a refusal"
    },
    {
     "value": "31,811",
     "label": "metered usage entries tied to the work that spent them"
    },
    {
     "value": "< 5 s",
     "label": "for another worker to resume a failed one from the graph"
    }
   ],
   "lede": "My long autonomous coding runs all failed the same way. The lead agent had to hold the operating procedure, the plan, every teammate's state and every piece of evidence in its context, and past some horizon it dropped one of them. The work then diverged quietly. I stopped treating that as a prompting problem. It is working-memory overflow, and the cure is to take the memory out of the model. AgentOS is the control plane I built on that diagnosis. The authoritative state of every engineering program lives in a PostgreSQL work graph. Each agent receives a small, freshly rendered, contract-bound job. Policy is enforced by machinery that refuses forbidden actions. Work closes only when an independent reviewer has the",
   "quote": "I forbade the most capable agent in the system from touching deliverables.",
   "evidence": [
    "Agent orchestration: a PostgreSQL work graph as the only source of truth for teams of AI coding agents, each given a small contract-bound job rendered at dispatch, across 246 work orders.",
    "Multi-agent governance: policy turned into refusals by 106 hook modules across eleven lifecycle events on the coding agents' own command-line tools, so a lead agent cannot edit an artifact.",
    "Separation of duties for AI work: builders, quality reviewers, a gatekeeper and an adversarial reviewer on a different vendor's model in distinct seats; an API platform closed all 23 of its close items under independent review.",
    "Cost attribution for AI work: 31,811 metered usage entries tied to the work that spent them, and in one program 3.197 billion tokens attributed to the penny across 11,193 priced model calls.",
    "Control-plane and state-machine architecture: a 546,000-line Rust control plane whose transition runtime gives the same state from the same inputs; a failed worker is resumed from the graph in under 5 s.",
    "Event-driven agent systems: per-seat mailboxes scoped to the team, with signed webhooks from payments, email or social-publishing providers turned into governed events and finite tasks for the owning lead."
   ]
  },
  {
   "url": "https://coreyjames.ai/systems/auth-and-access-plane/",
   "kind": "system",
   "title": "Auth and access plane",
   "subtitle": "How commercial AI assistants and my own agents reach a private tool estate: OAuth, token validation, edge exposure and an operations layer",
   "systems": [],
   "technologies": [
    "OAuth 2.0",
    "PKCE",
    "JWKS",
    "WebAuthn",
    "Python",
    "Edge workers",
    "NGINX",
    "systemd",
    "Redis",
    "Microsoft Copilot Studio"
   ],
   "stats": [
    {
     "value": "1 person",
     "label": "approves every grant on the consent screen"
    },
    {
     "value": "21 → 8",
     "label": "tools: the full local surface, and the trimmed one shown to Copilot Studio"
    },
    {
     "value": "2",
     "label": "token issuers the gateway accepts: my server and Microsoft's platform"
    }
   ],
   "lede": "My tool estate is private, and I wanted commercial AI assistants, including Microsoft Copilot Studio, to connect to it on my terms, alongside my own agents. The access plane is how they get in: an OAuth authorization server, gateway token validation against several issuers, an edge proxy that exposes a trimmed tool surface to a vendor's agent platform, and an operations layer that runs the estate. The idea The consent screen is the control. Assistants self-register as OAuth clients, and a human approves each grant. A security review once found anonymous registration with attacker-chosen redirects, I locked registration down, and the next morning every assistant was locked out. I re-ran the threat model: a hostile registration gains nothing unless a",
   "quote": "The lock looked like security; the consent step is security, because a human sees exactly which client is asking for exactly what.",
   "evidence": [
    "OAuth 2.0 and identity architecture: commercial AI assistants and my own agents admitted to a private tool estate as OAuth clients, with 1 person approving every grant on the consent screen.",
    "Delegated authorization for AI agents: one gateway that accepts tokens from 2 issuers, my own authorization server and Microsoft's platform, before any tool is visible.",
    "Microsoft Copilot Studio integration: an edge proxy that shows Copilot Studio a trimmed surface of 8 tools out of the 21 on the local surface, without opening the estate behind it.",
    "Zero-trust and zero-inbound networking: a private tool estate reached by commercial assistants with no open inbound ports.",
    "Security judgment under operational load: consent chosen over registration as the control point, and my own registration lock reverted the day after I added it."
   ]
  },
  {
   "url": "https://coreyjames.ai/systems/capabilities-model/",
   "kind": "system",
   "title": "Capabilities model",
   "subtitle": "A 0.6-billion-parameter model that memorises an agent's tool catalog, with the data, decoder, serving and evaluation around it",
   "systems": [],
   "technologies": [
    "PyTorch",
    "Hugging Face Transformers",
    "Full-parameter fine-tuning",
    "Grammar-constrained decoding",
    "CUDA",
    "Rust",
    "Model Context Protocol (MCP)",
    "Weight quantisation (W4A16)",
    "NVIDIA Blackwell GPUs"
   ],
   "stats": [
    {
     "value": "0.955",
     "label": "recall at 5 on 469 frozen queries; the best classical baseline scored 0.949"
    },
    {
     "value": "2,048",
     "label": "simultaneous clients in one burst, none failed or rejected"
    },
    {
     "value": "2.7 GiB",
     "label": "for the whole discovery engine on the shared card"
    }
   ],
   "lede": "An agent connected to a serious tool estate pays for that estate on every turn: the schema of every tool it might call is loaded into context whether it uses one or not. On my estate that was 44 tools across three servers, measured on the wire. The quieter failure is worse: an agent that cannot see the right tool concludes it has none and improvises. I replaced the catalog with a single discovery tool backed by a 0.6-billion-parameter model that has the catalog memorised and cannot name a tool outside it. Around that model is a complete small-model system: a registry-driven data factory, a CUDA decoder whose output bits do not depend on the batch, a serving engine that",
   "quote": "The baseline was weak. I struck it, built the strongest retriever I could assemble, and the model tied it.",
   "evidence": [
    "LLM fine-tuning for tool discovery: a 0.6-billion-parameter model fully fine-tuned on registry-generated data to memorise 44 tools across three servers, rebuilt in minutes when the catalog changes.",
    "Grammar-constrained decoding: a grammar compiled from the tool registry and applied during decoding, so the model cannot name a tool outside the catalog.",
    "Inference serving architecture: a batched, continuous CUDA decoding engine with paged key-value memory and typed refusals, 2.7 GiB on a card shared with a 30B model.",
    "Deterministic GPU computation: output bits identical across batch compositions through one block per output row, fixed-order reductions and no K-split tiling.",
    "ML evaluation methodology: recall at 5 of 0.955 on 469 frozen queries against 0.949 for the best classical baseline, published as a tie.",
    "Load testing for agent concurrency: 2,048 simultaneous clients in one burst, none failed or rejected."
   ]
  },
  {
   "url": "https://coreyjames.ai/systems/fafo-core/",
   "kind": "system",
   "title": "FAFO Core and Function Forge",
   "subtitle": "The execution substrate under everything else: one function definition becomes an orchestrated, budgeted, agent-callable tool",
   "systems": [],
   "technologies": [
    "Rust",
    "Redis Streams",
    "PostgreSQL",
    "Code generation",
    "Docker",
    "Federated provisioning",
    "Budget enforcement",
    "YAML schema compilation",
    "Model Context Protocol (MCP)"
   ],
   "stats": [
    {
     "value": "7 of 14",
     "label": "function crates written by the generator"
    },
    {
     "value": "19",
     "label": "control actions on a job in flight"
    },
    {
     "value": "180",
     "label": "actions across 18 tools, compiled from YAML schemas"
    },
    {
     "value": "23",
     "label": "close items on the integration platform, each with an independent verdict"
    }
   ],
   "lede": "Every organisation that puts AI agents to work hits the same wall. Each new capability needs its own integration, orchestration, database plumbing, rate limiting, compute and someone to run it. I was going to build many systems and I did not want to solve orchestration, data safety and spend control more than once. FAFO Core is the substrate where those are solved. One function definition becomes an orchestrated, controllable, agent-callable tool that runs against any registered data source, in-process or in a container on a local machine, a LAN workstation or a rented cloud GPU, under a budget a human set. Function Forge is the generator that lets an agent write such a function itself, inside a sandbox, callable only",
   "quote": "Rebuild and human restart is slower, and it is the governance step.",
   "evidence": [
    "Platform engineering for AI agents: one function definition becomes an orchestrated, budgeted, agent-callable tool, in-process or in a container, local, LAN or cloud, by configuration alone.",
    "Tool synthesis and governed API integration: a generator that let agents write 7 of 14 function crates in a sandbox, callable only after a human rebuild and restart.",
    "Job control planes: a Redis-stream command bus with atomic job promotion and 19 control actions on a job in flight, including pause, scale, drain and inspect.",
    "MCP server design: a model-facing gateway compiling YAML schemas into 180 actions across 18 tools.",
    "Rust systems engineering: about 168,000 lines across fourteen function crates and 45,000 in the core substrate, with link-time registration so nothing runs half-wired.",
    "Evidence-gated acceptance: a sibling API integration platform held open until all 23 close items had an independent verdict."
   ]
  },
  {
   "url": "https://coreyjames.ai/systems/fafohive/",
   "kind": "system",
   "title": "FAFOHive",
   "subtitle": "The MCP hub every agent in my estate connects to: memory and code intelligence, hosted tools, and a governed tool gateway",
   "systems": [],
   "technologies": [
    "Rust",
    "Model Context Protocol (MCP)",
    "tree-sitter",
    "PostgreSQL",
    "Redis",
    "Hybrid lexical and vector retrieval",
    "OAuth 2.0 and JWT",
    "Webhook signature verification",
    "Social platform APIs"
   ],
   "stats": [
    {
     "value": "475",
     "label": "tools behind one authenticated endpoint"
    },
    {
     "value": "294,033",
     "label": "of 294,362 code chunks covered by the computed graph"
    },
    {
     "value": "0",
     "label": "failures with two thousand agents calling at once"
    }
   ],
   "lede": "AI coding agents forget everything between sessions, rediscover the same facts about a codebase every day, and explain call paths that do not exist with complete confidence. Once they are allowed to act on real services they also need credentials they must never see. I solved those three problems in one service. FAFOHive is the authenticated MCP server every agent in my estate connects to. Inside it, a memory capability provides durable session memory and code intelligence grounded in a computed graph. Around that, FAFOHive hosts governance and media tools and a governed gateway to commercial and in-house integrations. Its tools, a minority of them native and the rest hosted or rebuilt from provider APIs, sit under one trust model",
   "quote": "A refusal beats a plausible guess, because the caveat is the first thing a reader stops seeing.",
   "evidence": [
    "MCP server design: one authenticated MCP hub with 475 tools behind one endpoint, under one trust model with three dispatch paths.",
    "Code intelligence for AI agents: a tree-sitter code graph of a 19,000-file multi-language monorepo with 294,033 of 294,362 code chunks covered, and an explainer that narrates only proven edges.",
    "Memory for AI agents: a Rust session-memory layer that captures every tool call as an observation, embeds it and re-injects relevant context into later sessions.",
    "Hybrid retrieval: code, observations and reference documents as three indexes behind one surface, lexical and dense search fused and reranked.",
    "Governed API integration for AI agents: payments, email and social providers rebuilt as my own tools with server-side credentials, plus in-house modules with 36 tools for X, 24 for Facebook and 6 for Reddit.",
    "Load testing with AI agent fleets: 0 failures with two thousand agents calling the service at once."
   ]
  },
  {
   "url": "https://coreyjames.ai/systems/helix/",
   "kind": "system",
   "title": "Helix",
   "subtitle": "Humans and several AI minds in one room, and one colleague who can be reached wherever the work is: in team chat, by voice, and in a Teams call",
   "systems": [],
   "technologies": [
    "C# / .NET 8",
    "Microsoft real-time media SDK",
    "Microsoft Graph",
    "Entra Agent ID",
    "Rust",
    "Tokio",
    "Audio pipeline engineering",
    "Speech recognition model",
    "Speech synthesis",
    "Mattermost"
   ],
   "stats": [
    {
     "value": "0.9 s",
     "label": "from the end of a question to the first spoken sound, down from 2.1"
    },
    {
     "value": "8 seats",
     "label": "from three model families, each with its own identity in the room"
    },
    {
     "value": "4",
     "label": "council designs; three rejected after real use, one adopted"
    },
    {
     "value": "30 min",
     "label": "Teams media soak with zero stalls, and a forced mid-call reconnect"
    }
   ],
   "lede": "Organisations adopting AI end up with a drawer of chatbots and dashboards. Helix is one place instead. On an open-source team chat server it is a multiplayer AI workspace: several humans and several model seats in one room, each seat a frontier model working under its own authenticated session with its own identity, answering only when addressed, keeping a conversation that survives restarts. In council mode the seats deliberate, challenge one another and ratify a plan with the human as chair. The same brain answers by voice, in a Microsoft Teams call, and in a meeting as a governed digital employee with its own Microsoft 365 identity. Durable work leaves the room as governed work orders in AgentOS and comes",
   "quote": "I rejected three of my own council designs in real use, because agreement without deliberation is worthless.",
   "evidence": [
    "Multi-agent collaboration systems: humans and eight model seats from three model families in one chat room, each seat under its own authenticated session and answering only when addressed.",
    "Consensus and deliberation protocols for AI agents: a council that closes only on exact unanimous agreement on a numbered revision, built four times with three designs rejected after real use.",
    "Real-time voice AI on local GPUs: a full-duplex Rust voice runtime of about 51,000 lines with 750 tests, question-to-first-sound cut from 2.1 s to 0.9 s, under a floor that only a person can take.",
    "Speech recognition and synthesis pipelines: GPU recognition cut from about a second to 38 to 74 ms, and streaming built for a voice model that came without it, first frame in about 300 ms.",
    "Microsoft Teams real-time media: a self-hosted AI participant in Teams calls over Microsoft's real-time media SDK, a 30-minute soak with zero stalls and a forced mid-call reconnect.",
    "Identity for AI agents in Microsoft 365 and Entra: a digital employee with its own Microsoft 365 identity acting in meetings, with tokens minted per employee on the server."
   ]
  },
  {
   "url": "https://coreyjames.ai/systems/inference-fabric/",
   "kind": "system",
   "title": "Inference Fabric",
   "subtitle": "A throughput-first GPU inference pipeline on consumer NVIDIA hardware: broker, saturated runtime, completion, vector store",
   "systems": [],
   "technologies": [
    "Rust",
    "C++",
    "CUDA",
    "TensorRT-LLM",
    "FP8 inference",
    "Memory-mapped storage",
    "Approximate nearest-neighbour search",
    "Prometheus and Grafana",
    "NVIDIA Blackwell GPUs"
   ],
   "stats": [
    {
     "value": "15",
     "label": "hand-written CUDA kernel families, native Blackwell binaries, no JIT"
    },
    {
     "value": "0",
     "label": "allocations after the first second of a profile, down from 4,236"
    },
    {
     "value": "4.95 M",
     "label": "tasks on one GPU over ten hours, zero retries"
    },
    {
     "value": "126K",
     "label": "lines of first-party Rust, C++ and CUDA across six trees"
    }
   ],
   "lede": "Large offline model workloads are throughput problems. Synthetic data, probe generation, hidden-state extraction and bulk embedding analytics do not care about response time; they care whether the GPU is busy. A request-and-response serving stack wastes GPU time on padding and idle gaps and ties producers to GPUs for hours. I built the Inference Fabric for throughput. Producers drop millions of tokenised tasks and walk away. A broker that understands tokens organises the work so GPUs barely pad. Pull-based GPU workers stay saturated on mixed hardware. Results land in the database when they finish. Vector outputs flow into a GPU-native store that searches and scores cluster quality. On two NVIDIA Blackwell GPUs it ran a 7-billion-parameter dense model in FP8 at",
   "quote": "I did not replace NVIDIA's inference; I fed it.",
   "evidence": [
    "High-throughput batch inference: a 7-billion-parameter dense model in FP8 at 163,000 tokens per second on two NVIDIA Blackwell GPUs, and 4.95 M tasks on one GPU over ten hours with zero retries.",
    "Token-aware scheduling: a durable broker on memory-mapped append-only logs that groups work by token shape and packs to each GPU's declared limits, with 0.42% padding waste and 99.9% prefix cache hits across two cards.",
    "TensorRT and TensorRT-LLM engineering: a pull-based saturation runtime around stock TensorRT-LLM kernels with a zero-allocation hot path, 4,236 allocations in the first second of an Nsight profile and none after.",
    "CUDA kernel development: fifteen hand-written kernel families compiled to native Blackwell binaries with no JIT, computing 38 per-cluster health metrics and exact, inverted-file and lattice vector search, each with a CPU reference.",
    "Distributed systems correctness: work retired only when its completion is acknowledged, so a restart never re-runs work the GPUs already hold, with 12.3 B tokens received and 12.3 B routed, a difference of zero.",
    "Cloud GPU provisioning with cost controls: one call stands up a consumer node locally, on a LAN host over mutual TLS or on rented cloud spot capacity, behind a fail-closed daily dollar budget."
   ]
  },
  {
   "url": "https://coreyjames.ai/systems/postgresql-fabric/",
   "kind": "system",
   "title": "PostgreSQL Fabric",
   "subtitle": "One governed write path for a GPU-scale estate: batches sized from the database's own limits, workers that follow the queue, admission that reads the database's pressure, and the heavy work run inside the database next to its indexes",
   "systems": [],
   "technologies": [
    "PostgreSQL",
    "PostgreSQL bulk-update engineering",
    "Write-behind persistence",
    "Admission control and rate limiting",
    "Redis",
    "Lua",
    "sqlx",
    "Database performance diagnosis",
    "pgvector",
    "Rust"
   ],
   "stats": [
    {
     "value": "0.3 s",
     "label": "a batch update that had taken more than 25 seconds"
    },
    {
     "value": "400 GB",
     "label": "of indexes that no query had ever read, removed"
    },
    {
     "value": "16,000",
     "label": "lines of Rust in the writer and its library, the queue logic in Lua"
    }
   ],
   "lede": "Every system in my estate reads PostgreSQL directly and writes it through one path. Hundreds of GPU and CPU workers produce results at the speed of the hardware, and a database that received each of those writes as it happened would spend its life holding connections and locks across GPU waits, with write load tracking GPU throughput rather than what the database can absorb. PostgreSQL Fabric is the layer that turns that firehose into batched, ordered, admitted writes, and that carries the work which belongs inside the database to the database. The idea Producers never hold a database connection for a write. Each write is serialised into a stream message with its destination, its operation, its payload and the width",
   "quote": "A self-tuning system that can be hand-tuned will be mistuned.",
   "evidence": [
    "PostgreSQL performance tuning: a batch update that had taken more than 25 seconds brought to 0.3 s.",
    "Index cost analysis: 400 GB of indexes that no query had ever read, removed and counted as write cost.",
    "Write-behind persistence: hundreds of GPU and CPU workers hand off their writes and move on, with no producer holding a database connection.",
    "Database admission control: writes admitted against the database's own pressure, proven in shadow mode before it could refuse one.",
    "Rust systems engineering: 16,000 lines of Rust in the writer and its library, with the queue logic in Lua."
   ]
  },
  {
   "url": "https://coreyjames.ai/capabilities/ai-teammates-in-teams-and-chat/",
   "kind": "capability",
   "title": "AI teammates inside Microsoft Teams and team chat",
   "subtitle": "A colleague people can call, interrupt and invite to meetings, under an identity the organisation governs",
   "systems": [
    "helix"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "30 min",
     "label": "Teams media soak from Azure to my own GPUs, zero receive stalls"
    },
    {
     "value": "67 ms",
     "label": "round-trip media latency across the bridge at most, 65 ms at best, single probe"
    },
    {
     "value": "13",
     "label": "meeting actions, each with an exact schema, served under the employee's identity"
    }
   ],
   "lede": "I built a digital employee in my own Microsoft 365 tenant. It answers calls with speech models on my own GPUs, stops when a person talks over it, joins meetings and posts in chat as itself. Underneath is the real-time media bridge I built between Microsoft's Windows-only media stack and a Linux voice engine. Start with A self-hosted colleague in a Teams call. design <figure class=\"dv-figure\" aria-label=\"One Teams call carried across two operating systems by one audio seam\" <span class=\"eyebrow\" One call, two operating systems, one audio seam</span <div class=\"dv-two\" style=\"margin-top: 0.8rem\" <div <span class=\"eyebrow\" Azure · Windows</span <div class=\"obj\" style=\"margin-top: 0.5rem\" <strong Media bridge</strong <span class=\"d\" joins the call on Microsoft's real-time media SDK and moves 20 ms audio",
   "quote": "I worked out the Microsoft identity layer from real tenant evidence where the documentation ran out.",
   "evidence": [
    "Microsoft Teams real-time media: a Windows media bridge on Microsoft's real-time media SDK joined to a Linux voice engine on my own GPUs, through a 30-minute soak with zero receive stalls.",
    "Binary wire protocol design: one authenticated audio channel per call, written in C# and in Rust and proven byte-identical against golden vectors, recovering a forced mid-call reconnect in one 250 ms retry.",
    "Identity for AI agents in Microsoft 365 and Entra: three Microsoft principals composed into one digital employee, with employee-scoped tokens minted on the server and never held by the model.",
    "MCP server design: 13 meeting actions with exact schemas served under the employee's identity, failing closed with a named reason where the platform offers no supported path.",
    "Real-time voice AI: round-trip media latency of 65 to 67 ms across the bridge, with call audio kept off third-party AI clouds."
   ]
  },
  {
   "url": "https://coreyjames.ai/capabilities/business-systems-as-safe-agent-tools/",
   "kind": "capability",
   "title": "Business systems as safe agent tools",
   "subtitle": "Agents acting on payments, email, social platforms and private APIs without holding a key, with every action attributed",
   "systems": [
    "fafohive",
    "fafo-core",
    "auth-and-access-plane"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "0",
     "label": "provider keys held by any agent; every credential stays server-side"
    },
    {
     "value": "7 of 14",
     "label": "function crates in the estate carry the tool generator's fingerprints"
    },
    {
     "value": "1 person",
     "label": "approves every grant an outside assistant receives, on the consent screen"
    }
   ],
   "lede": "Agents that do real work against real services need credentials, and the moment one holds a credential there is a key in a transcript, actions nobody can attribute, and a crash window where a charge is doubled or lost. I built a governed gateway that exposes provider tools, each rebuilt from the provider's API, to managed agents, with credentials held server-side and identity derived from the authenticated caller, so no tool argument can claim to be someone else. Start with Agents with real tools and no keys. design <figure class=\"dv-figure\" aria-label=\"The crash window around a provider call, and the return path for vendor events\" <span class=\"eyebrow\" The crash window around one provider call</span <div style=\"display: flex; min-height: 34px; border-radius: 8px;",
   "quote": "Attribution that might be silently dropped is worse than none.",
   "evidence": [
    "Tool synthesis and governed API integration: payments, email and social-publishing provider APIs rebuilt as agent tools behind one gateway, with 0 provider keys held by any agent.",
    "Exactly-once delivery and crash recovery: durable accounting around every provider call so a restart never repeats it, and vendor events returned signed to the team that caused them.",
    "Attribution design for agent actions: a per-provider capability table that writes attribution into a vendor payload only where that operation was shown to round-trip it.",
    "Sandboxed code generation for agents: a generator emitting 8 framework and 6 sandboxed files per tool, callable only after a human restart, with 7 of 14 function crates carrying its fingerprints.",
    "OAuth 2.0 and identity architecture: an access plane where 1 person approves every grant an outside assistant receives, on the consent screen."
   ]
  },
  {
   "url": "https://coreyjames.ai/capabilities/governed-autonomous-engineering/",
   "kind": "capability",
   "title": "Governed autonomous engineering",
   "subtitle": "Programs of AI coding agents that finish, prove it, and can be trusted",
   "systems": [
    "agentos",
    "agent-swarm"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "246",
     "label": "work orders governed, including every program on this page"
    },
    {
     "value": "45,097",
     "label": "state transitions, each one leaving a receipt"
    },
    {
     "value": "1,000+",
     "label": "passing trials voided when I found they were testing the wrong thing"
    }
   ],
   "lede": "AI coding agents can carry substantial engineering only if the output can be trusted. Agents over-claim, drift as their context fills, and optimise for whatever metric is in front of them. design <blockquote class=\"dv-quote\" <p Longer prompts and more human review do not scale.</p </blockquote The method is written down and enforced by machinery I built, and work closes only on evidence. design <figure class=\"dv-figure\" aria-label=\"A long session loses its rules as context fills; a governed job carries only the slice it needs\" <div class=\"dv-two\" <div <span class=\"eyebrow\" One long session</span <div style=\"position: relative; margin-top: 1.6rem\" aria-hidden=\"true\" <div style=\"position: absolute; left: 22%; right: 0; top: -12px; height: 44px; border: 2px solid var(--ink-3); border-bottom: 0; border-radius: 8px 8px 0 0\" </div",
   "quote": "Longer prompts and more human review do not scale.",
   "evidence": [
    "AI-assisted engineering methodology: programs of AI coding agents under a written method enforced by machinery I built, 246 work orders governed and 45,097 state transitions each leaving a receipt.",
    "Agent orchestration: each job rendered at dispatch from the slice of the work graph it needs, with a schema for what must come back, so nothing is carried from job to job in a model's head.",
    "Separation of duties for AI work: builders from one model family judged by a different vendor's models, and a 27-gate swarm phase closed as a conditional pass with two failures rather than narrowed criteria.",
    "Evidence-gated acceptance: 1,000+ passing trials voided when I found they were testing the wrong thing, and a genuine gain rejected because its cutoff matched the test fixture.",
    "C++ and native ports with parity proof: the ActiveKV native port, bit-identical in every parity cell in under three weeks, with zero Python files in the release.",
    "Technical leadership of agent teams: data, training, a custom decoder, serving and a frozen evaluation for a model program under a single work order with an independent quality seat."
   ]
  },
  {
   "url": "https://coreyjames.ai/capabilities/gpu-vector-search-and-corpus-analytics/",
   "kind": "capability",
   "title": "GPU vector search and corpus analytics",
   "subtitle": "Vectors that stay out of the database yet verifiably tied to it, searched and scored on the GPU",
   "systems": [
    "inference-fabric"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "0.85",
     "label": "recall at ten against exact search, the inverted-file floor asserted in continuous integration"
    },
    {
     "value": "10⁻⁴",
     "label": "relative tolerance between every kernel and its CPU reference"
    },
    {
     "value": "~100 s",
     "label": "to rebuild the GPU files from four million rows, the cost a delta build avoids"
    }
   ],
   "lede": "Embeddings are often too large and too hot for the relational database, and the moment they leave it there is no way to say which row a vector belongs to, or whether the index being searched is any good. I built vector storage leased to the GPU that stays verifiably tied to its relational source, with index-quality reporting so retrieval health is visible. See An index you can rebuild from its receipt and The database decides when an index goes stale. design <figure class=\"dv-figure\" aria-label=\"An index built twice, once from shuffled input, producing the same artifact hash; and an append that marks it stale\" <span class=\"eyebrow\" The receipt every build carries</span <div style=\"display: grid; grid-template-columns: 9rem minmax(0, 1fr); gap: 0.8rem;",
   "quote": "A GPU kernel that computes a statistic is a poor definition of that statistic.",
   "evidence": [
    "Vector search and ANN indexes: exact, inverted-file and lattice search on the GPU, with a recall-at-ten floor of 0.85 against exact search asserted in continuous integration.",
    "Data provenance for retrieval: every index build carries configuration, training-set and artifact hashes, and a rebuild from shuffled input gives byte-identical artifacts.",
    "Database-driven index invalidation: a trigger marks every index over a shard stale the moment its journal advances, and the loader refuses a mismatched file with a reason.",
    "Incremental rebuild design: delta builds byte-identical to the full build, chosen by shape with a full rebuild past 10% of the table or 100,000 pending rows, sparing a ~100 s full rebuild.",
    "CUDA kernel development: kernels written from Rust against the driver API, each held to a CPU reference at a relative tolerance of 10⁻⁴.",
    "Embedding analytics and cluster metrics: search and cluster health from the same read, through a NaN-filled side-band reduced to cohesion and inertia per cluster."
   ]
  },
  {
   "url": "https://coreyjames.ai/capabilities/high-throughput-batch-inference/",
   "kind": "capability",
   "title": "High-throughput batch inference and embeddings",
   "subtitle": "Millions of items through GPUs I own, with the hardware kept busy and the accounting balanced",
   "systems": [
    "inference-fabric",
    "fafo-core"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "0.42%",
     "label": "padding waste across the two cards, with zero shape switches"
    },
    {
     "value": "99.9%",
     "label": "engine cache hit rate, from shape-pure batches"
    },
    {
     "value": "4.95 M",
     "label": "tasks on one GPU over a ten-hour run, zero retries"
    }
   ],
   "lede": "Offline workloads, synthetic data, extraction, bulk embeddings, are throughput problems, and a serving stack built for chat treats them like chat: padding, idle gaps, producers tied to GPUs for hours, results persisted by whoever is still waiting. I took one model from about 44,000 tokens per second on one NVIDIA Blackwell GPU to a five-minute mean of 163,000 on two NVIDIA Blackwell GPUs without touching a kernel, by building the layers around the engine. Start with From 44K to 163K tokens per second. design <blockquote class=\"dv-quote\" <p I did not replace NVIDIA's inference; I fed it.</p </blockquote The first layer is a broker whose unit of scheduling is the token, feeding pull-based workers that stay saturated on mixed hardware. See",
   "quote": "I did not replace NVIDIA's inference; I fed it.",
   "evidence": [
    "High-throughput batch inference: one 7B dense model in FP8 taken from about 44,000 to a five-minute mean of 163,000 tokens per second on two NVIDIA Blackwell GPUs without touching a kernel.",
    "Token-aware scheduling: shape-pure batches packed to each card's four-number contract, with 0.42% padding waste and a 99.9% engine cache hit rate across two mismatched cards.",
    "Distributed systems correctness: done redefined as acknowledged after 6.67 M pending items proved to be 118 K in storage, leaving 12.3 B tokens received and 12.3 B routed.",
    "Inference serving architecture: per-card engine tiers of 524K and 98K tokens per step from one checkpoint, so a slow card slows only itself.",
    "GPU inference optimisation: 4.95 M tasks on one GPU over a ten-hour run with zero retries."
   ]
  },
  {
   "url": "https://coreyjames.ai/capabilities/longer-context-on-the-gpus-you-own/",
   "kind": "capability",
   "title": "Bigger models and longer context on fixed GPU memory",
   "subtitle": "When GPU memory, not the workload, is the limit",
   "systems": [
    "activekv",
    "capabilities-model"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "13 of 13",
     "label": "exact cells bit-identical to fully resident attention at the native port, 12 of 12 hybrid"
    },
    {
     "value": "0",
     "label": "Python files in the release payload of the memory layer"
    },
    {
     "value": "+36%",
     "label": "sustained output throughput of the 4-bit build over the mixed 4- and 8-bit control, 64 clients"
    }
   ],
   "lede": "A model's context, or the number of long sessions that can stay alive, is capped by the memory on the cards at hand. The usual answers are bigger cards, more cards or less context. I built an inference-memory layer for vLLM that moves a context's history into host RAM and treats the GPU as a bounded working set, with an exact tier that is bit-identical to fully resident attention. I ported it entirely to native C++ under parity gates, as a patch that applies to an unmodified vLLM. Start with Context beyond VRAM. design <figure class=\"dv-figure\" aria-label=\"Where the memory layer is faster than stock vLLM and where stock is still faster\" <span class=\"eyebrow\" Where the trade sits</span <div class=\"dv-two\" style=\"margin-top:",
   "quote": "Exactness is a property I want in the system.",
   "evidence": [
    "KV-cache offload for LLM inference: a context's history in host RAM and the GPU as a bounded working set inside vLLM, with an exact tier bit-identical to fully resident attention in 13 of 13 cells.",
    "C++ and native ports with parity proof: the memory layer ported entirely to native C++ under parity gates, 12 of 12 hybrid cells matching and 0 Python files in the release payload.",
    "LLM quantization (4-bit): a 27B model fitted on one 32 GB Intel card as a W4A16 build, +36% sustained output throughput over the mixed control at a stated 3.33% perplexity cost.",
    "Intel GPU and SYCL/oneAPI engineering: vendor kernel patches on new silicon with identical outputs, cutting a cold 32K-token prefill from 21.54 s to 17.23 s.",
    "Performance benchmarking methodology: time to first token of 3.68 s against stock vLLM's 4.71 s on a single 8K request, with the 128K regime where stock still decodes faster stated beside it."
   ]
  },
  {
   "url": "https://coreyjames.ai/capabilities/memory-and-code-intelligence-for-agents/",
   "kind": "capability",
   "title": "Memory and code intelligence for agents",
   "subtitle": "Agents that remember across sessions and explain code without inventing it",
   "systems": [
    "fafohive"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "294,033",
     "label": "of 294,362 code chunks covered by the computed graph"
    },
    {
     "value": "0",
     "label": "models involved in a dependency trace; it is a bounded database traversal"
    },
    {
     "value": "3",
     "label": "indexes, code, past decisions and reference documents, behind one retrieval surface"
    }
   ],
   "lede": "Coding agents forget everything between sessions, rediscover the same facts about a codebase daily, and explain call paths that do not exist with complete confidence. I built the memory and code-intelligence service every agent in my estate connects to. Dependency tracing is a graph query, and the code explainer narrates only edges the graph has proven and refuses when coverage is incomplete. Start with A code explainer that is not allowed to invent. design <figure class=\"dv-figure\" aria-label=\"A path through the code graph, traversed before the model sees it\" <span class=\"eyebrow\" Compute first, narrate second</span <div style=\"position: relative; height: 140px; margin-top: 0.6rem\" aria-hidden=\"true\" <svg viewBox=\"0 0 100 100\" preserveAspectRatio=\"none\" style=\"position: absolute; inset: 0; width: 100%; height: 100%\" <line x1=\"8\" y1=\"50\" x2=\"32\"",
   "quote": "A refusal beats a plausible guess, because the caveat is the first thing a reader stops seeing.",
   "evidence": [
    "Code intelligence for AI agents: a tree-sitter code graph covering 294,033 of 294,362 code chunks, with dependency tracing as a bounded database traversal and 0 models involved.",
    "Evidence-grounded LLM output: a code explainer that narrates only edges the graph has proven and returns coverage incomplete, with no free-form fallback.",
    "Persistent agent memory: session memory that captures every tool call as an observation, extracts and embeds it, and re-injects it into later sessions.",
    "Retrieval system design: code, past decisions and reference documents as 3 indexes behind one retrieval surface."
   ]
  },
  {
   "url": "https://coreyjames.ai/capabilities/small-models-for-tool-calling-and-routing/",
   "kind": "capability",
   "title": "Custom small models for tool calling and routing",
   "subtitle": "When a 0.6B model that cannot be wrong in the dangerous way beats a large model reading a catalog",
   "systems": [
    "capabilities-model"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "2,048",
     "label": "simultaneous clients in one burst, none failed or rejected"
    },
    {
     "value": "2,740",
     "label": "MiB, the engine's whole footprint, on the card the larger serving model already uses"
    },
    {
     "value": "12 of 12",
     "label": "bit-identity gates passed across batch compositions"
    }
   ],
   "lede": "Every tool an agent can reach is described to it on every turn, and the bill and the latency grow with the estate. Meanwhile an agent that cannot see the right tool improvises. I compiled a tool catalog into a fine-tuned 0.6-billion-parameter model that cannot name a tool outside the catalog, with a decoder whose output bits are identical across batch compositions. Start with A hundred tokens instead of forty-two thousand and Bit-identical across batch compositions. design <figure class=\"dv-figure\" aria-label=\"The decoder can only emit names in the catalog, and its answer does not change with the batch\" <div class=\"dv-two\" <div <span class=\"eyebrow\" What the decoder can say</span <div style=\"border-radius: 10px; border: 1.5px solid var(--purple); background: var(--purple-soft); padding: 0.7rem; margin-top: 0.8rem\"",
   "quote": "A wrong real tool name is a recoverable error; a plausible fake one is a silent failure.",
   "evidence": [
    "Small language models for tool routing: a 0.6B model fine-tuned on a tool catalog with a decoder that cannot name a tool outside it, serving 2,048 simultaneous clients with none failed.",
    "Deterministic GPU computation: a CUDA decoder bit-identical across batch compositions, 12 of 12 gates passed and all 2,345 shuffled compositions agreeing on the top result.",
    "ML evaluation methodology: 469 frozen queries over 42 tools against the strongest classical baseline, published as a tie at 0.955 against 0.949 and a loss of 0.67 against 0.90 on buried requests.",
    "Inference serving on a shared GPU: a 2,740 MiB engine beside a 30B model that admits work against measured memory, with a missed throughput target reported with its cause."
   ]
  },
  {
   "url": "https://coreyjames.ai/capabilities/use-the-ai-subscriptions-you-already-have/",
   "kind": "capability",
   "title": "AI subscriptions as governed workers",
   "subtitle": "Running vendors' authenticated command-line tools as governed workers, alongside API-keyed and local models",
   "systems": [
    "agentos",
    "helix",
    "agent-swarm"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "31,811",
     "label": "metered usage entries, each tied to the work that spent it"
    },
    {
     "value": "94.5%",
     "label": "overall cache hit rate across one priced engineering program"
    },
    {
     "value": "30 s",
     "label": "deadline for a vendor session to confirm a prompt arrived, by its own transcript event"
    }
   ],
   "lede": "My governance platform runs real interactive sessions of vendors' authenticated command-line tools, under my own logins, as durable governed seats, alongside API-keyed seats and local open-source models served on my own GPUs. design <figure class=\"dv-figure\" aria-label=\"A vendor's command-line session hosted as a governed seat\" <div class=\"dv-two\" <div <span class=\"eyebrow\" A subscription seat</span <div style=\"margin-top: 0.8rem; border-radius: 10px; background: var(--navy); padding: 0.8rem 0.9rem\" aria-hidden=\"true\" <div style=\"display: flex; gap: 5px; margin-bottom: 0.7rem\" <i style=\"width: 9px; height: 9px; border-radius: 50%; background: var(--on-navy-3)\" </i <i style=\"width: 9px; height: 9px; border-radius: 50%; background: var(--on-navy-3)\" </i <i style=\"width: 9px; height: 9px; border-radius: 50%; background: var(--on-navy-3)\" </i </div <div style=\"display: grid; gap: 6px\" <i style=\"display: block; width: 70%; height: 7px; border-radius: 3px; background: var(--on-navy-3)\" </i <i style=\"display:",
   "quote": "Builders and reviewers come from different model families so their blind spots do not overlap.",
   "evidence": [
    "Agent orchestration across vendors: vendors' authenticated command-line tools run as durable governed seats beside API-keyed and local open-weight seats, under the same acceptance rules.",
    "Cost attribution for AI work: 31,811 metered usage records tied to the work that spent them, and one program costed by phase with a 94.5% overall cache hit rate.",
    "Separation of duties for AI work: builders and reviewers drawn from different model families so their blind spots do not overlap.",
    "Prompt delivery assurance: a prompt counts as delivered only when the provider's own transcript shows it, within a 30 s acceptance deadline."
   ]
  },
  {
   "url": "https://coreyjames.ai/capabilities/voice-agents-in-meetings/",
   "kind": "capability",
   "title": "Voice agents in calls and meetings",
   "subtitle": "Speech recognition, synthesis and turn-taking on my own hardware, joined to the platforms people already use",
   "systems": [
    "helix"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "25×",
     "label": "faster speech recognition on the GPU than on the CPU path, 18× at the least, in real turns"
    },
    {
     "value": "< 1 ms",
     "label": "to play the lines an assistant says most, pre-rendered per voice"
    },
    {
     "value": "5,668",
     "label": "turns in a ten-minute loopback soak, every one processed"
    }
   ],
   "lede": "An AI that people can talk to in a real call has to answer in conversational time, stop when it is interrupted, and keep the audio away from third-party AI services. I built a conversational voice engine in Rust with speech recognition, neural speech synthesis, floor control so several AI voices share one conversation without talking over each other, interruption handling so a person speaking stops the agent, and tool calls made mid-conversation. The gap between the end of a question and the first sound of the reply was taken apart stage by stage. See From two seconds to under one. design <figure class=\"dv-figure\" aria-label=\"Question to first sound, cut into stages, before and after\" <span class=\"eyebrow\" Question to first sound",
   "quote": "A proof that passes with the wrong input is a proof of the test harness.",
   "evidence": [
    "Real-time voice AI: a Rust conversational engine on my own GPUs with question-to-first-sound cut from about 2.1 s to about 0.9 s, stage by stage.",
    "Speech recognition and synthesis pipelines: recognition on a GPU at 38 to 74 ms per turn, 18 to 25 times faster than the CPU path, and streaming built for a voice model that had none.",
    "Full-duplex barge-in design: interruptions that only a person can make, with the agent's own echo below a measured threshold and a false stop re-spoken.",
    "Test methodology with negative controls: an echo-cancellation score of 36.8 dB exposed when an unrelated reference scored 37.8 dB, and the proof rebuilt with a control.",
    "Latency diagnosis: a slow Teams turn traced to a shared speech GPU, about 78% of the turn against about 1% for the network, so compute moved and the cloud bridge stayed."
   ]
  },
  {
   "url": "https://coreyjames.ai/ideas/a-human-at-the-privileged-step/",
   "kind": "idea",
   "title": "A human at the privileged step",
   "subtitle": "Automate everything up to the one action that carries real authority, and put a person exactly there",
   "systems": [
    "fafo-core",
    "agentos",
    "auth-and-access-plane",
    "fafohive"
   ],
   "technologies": [],
   "stats": [],
   "lede": "Full autonomy is a slogan and so is a human in every loop. I put the human at the one step that carries real authority, putting a generated tool into service, setting a day's spend, approving a client's grant, unlocking a work order, deciding the fate of an uncertain send, and nowhere else. The gate sits at the narrowest point, so agents keep their speed everywhere else and the human's attention is spent where it changes something. The shape Identify the action whose consequence cannot be undone or whose authority cannot be delegated. Build the automation to run flat out up to that action and to stop there with everything prepared. Make the human step small and explicit. Keep the",
   "quote": "The gate is placed by consequence, not by fear.",
   "evidence": [
    "Human-in-the-loop design for AI agents: a person placed only at the step that carries authority, such as deploying a generated tool, setting a day's spend or approving a grant, with agents working flat out up to it.",
    "Governed tool synthesis: agent-authored tools take effect only when a human rebuilds and restarts the gateway, and the budget path sits on no agent's tool surface.",
    "OAuth consent as a control point: assistants register themselves and a person approves each grant on the consent screen."
   ]
  },
  {
   "url": "https://coreyjames.ai/ideas/agents-that-react-to-the-world/",
   "kind": "idea",
   "title": "Agents that react to the world",
   "subtitle": "Mailboxes, inbound event sources and standing work orders, so an agent team runs on what happens and never only on prompts",
   "systems": [
    "agentos",
    "agent-swarm",
    "fafohive"
   ],
   "technologies": [],
   "stats": [],
   "lede": "An agent that only answers prompts is a tool. An agent team that runs a business has to react to things that happen while nobody is typing: a payment lands, a customer replies, a post gets a comment, a document arrives, a job finishes somewhere else. I built the agent platform so that every seat has a mailbox, every external system can become a governed event source, and a work order can stay open indefinitely as a standing lead that turns events into finite tasks and brings specialists online when they are needed. The shape Every team lead and every seat has a mailbox. Seats can message only their own team, and the identity on every message is derived on",
   "quote": "An event that becomes a task inherits budgets, evidence and review for free.",
   "evidence": [
    "Event-driven agent systems: signed provider webhooks checked at an edge, persisted, batched and delivered across hosts into a work order's team-lead mailbox as finite governed tasks.",
    "Exactly-once delivery and crash recovery: uncertain event batches retained, never dropped and never blindly replayed, with receipt causing no provider-side effect.",
    "Agent orchestration for continuous operations: standing work orders with an open-ended envelope that admit tasks as events arrive and bring specialist seats online on demand."
   ]
  },
  {
   "url": "https://coreyjames.ai/ideas/append-only-with-lineage/",
   "kind": "idea",
   "title": "Append-only, with tombstones and lineage",
   "subtitle": "Durable logs are only ever appended, deletion is a mark, and every derived artefact can prove where it came from",
   "systems": [
    "inference-fabric",
    "agentos",
    "fafohive",
    "activekv"
   ],
   "technologies": [],
   "stats": [],
   "lede": "When the history of what happened can be rewritten, recovery becomes archaeology. I build the durable state in my systems as append-only logs. Completion or deletion is a tombstone written in place, in a fixed order relative to the data it refers to, so that a crash between two writes is repaired by a scan rather than a guess. Every derived artefact, an index, an extraction, a projection, carries a hash or a reference back to its source, so lineage is a property of the data and not a convention. The shape Writes append. A segment or a table is never rewritten in place except for the tombstone mark. Derived artefacts carry the identity of their inputs and the parameters",
   "quote": "I pay both, because the alternative is a second bookkeeping file that can disagree with the data.",
   "evidence": [
    "Append-only log design: memory-mapped append-only segments where completion is a tombstone written at the entry's offset and recovery reads only tombstones.",
    "Exactly-once delivery and crash recovery: a fixed write order, output persisted before the tombstone and the input retired last, so every recovery path is a scan.",
    "Data provenance and lineage: derived indexes, extractions and projections carry the identity of their inputs, checked at build, persist and load and refused on mismatch."
   ]
  },
  {
   "url": "https://coreyjames.ai/ideas/authority-outside-the-model/",
   "kind": "idea",
   "title": "Authority outside the model",
   "subtitle": "The model is a nondeterministic worker inside a deterministic system that decides what it may do, what step it is on, and whether it is finished",
   "systems": [
    "agentos",
    "agent-swarm",
    "fafohive",
    "fafo-core"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "326",
     "label": "active actions in one busy work order"
    },
    {
     "value": "9",
     "label": "states each of those actions can be in"
    },
    {
     "value": "52",
     "label": "legal transitions in the whole governance map, across all states"
    }
   ],
   "lede": "A language model is a superb worker and a terrible authority. It will do the task in front of it with skill, and it will also decide it has permission it was never given, declare a step complete because the transcript reads that way, and talk itself out of a rule that is inconvenient. Every failure I had with autonomous agents came back to the same cause: the model was being asked to hold the authority as well as do the work. I now build systems where the model never decides what it is allowed to do, what step it is on, or whether it is finished. External rules, data and machinery decide all of that. The shape State lives",
   "quote": "Anything the system can decide deterministically, the system decides, and the model is left with the work that requires judgment.",
   "evidence": [
    "Multi-agent governance: agent state held in a database and policy enforced by hooks that refuse forbidden actions; one busy work order holds 326 active actions in 9 states, governed by a map of 52 legal transitions.",
    "Identity and least privilege for AI agents: identity derived from how an agent authenticated, never its claims in a tool call, a budget it cannot raise, and agent-written tools that take effect only after a human rebuilds the gateway.",
    "Evidence-gated acceptance: completion judged by evidence in the system and examined by a reviewer that did not do the work, with a work order closing as one act over all of its acceptance evidence."
   ]
  },
  {
   "url": "https://coreyjames.ai/ideas/budgets-and-refusals/",
   "kind": "idea",
   "title": "Budgets and refusals",
   "subtitle": "Spend, memory and admission are first-class controls, and the system says no with a number instead of degrading",
   "systems": [
    "fafo-core",
    "activekv",
    "capabilities-model",
    "agentos"
   ],
   "technologies": [],
   "stats": [],
   "lede": "Every resource an agent or a kernel can consume has a stated limit in my systems, and crossing it produces a typed refusal with a reason attached. Dollars per day, device pages per context, key-value memory per request, concurrent sequences per engine, tokens per step. The alternative, letting the system find its own limit by thrashing, stalling or running out of memory mid-step, hides the failure where it is most expensive to find. The shape The limit is explicit and set by a human: a whole number of gibibytes, a dollar figure, a count. Admission checks the limit before load is taken on. Budgets sit in paths an agent cannot reach from inside the work; an agent that wants more",
   "quote": "Fail closed where the silent alternative is money, loss or a false result; degrade gracefully where the alternative is merely lower quality.",
   "evidence": [
    "Admission control and rate limiting: typed refusals at the door carrying how much was needed, how much was available and whether a retry can help, instead of failing mid-step.",
    "Cloud GPU provisioning with cost controls: a fail-closed daily dollar budget, set by a person on a path agents cannot reach, gating GPU provisioning on local, LAN and cloud hardware.",
    "GPU memory management: an explicit device page pool with per-context floors, targets and bursts, and cache pages reserved for a whole answer at admission."
   ]
  },
  {
   "url": "https://coreyjames.ai/ideas/compute-first-narrate-second/",
   "kind": "idea",
   "title": "Compute first, narrate second",
   "subtitle": "Put deterministic evidence in front of the model instead of asking the model for evidence",
   "systems": [
    "fafohive",
    "agentos",
    "capabilities-model",
    "helix"
   ],
   "technologies": [],
   "stats": [],
   "lede": "A model asked \"how does this code work\" will answer fluently and will invent call paths. A model asked \"is this task done\" will say yes. A model asked \"which tool should I use\" will name one that does not exist. In each case the failure is the same: the model was asked to produce evidence. I build the other way round. Whatever can be computed is computed first, by code that cannot hallucinate, and the model's job is reduced to narrating or acting on what it was handed. The shape A deterministic layer produces the facts: a code graph, a work-order state, a tool registry, a room-state projection from a meeting. The model receives those facts in its context",
   "quote": "The caveat is the first thing a reader stops seeing, so I do not build that path.",
   "evidence": [
    "Evidence-grounded LLM output: a code explainer that narrates only edges a bounded graph query has proven and reports incomplete coverage instead of guessing.",
    "Grammar-constrained decoding: a grammar compiled from the tool registry, so a model cannot name a tool that does not exist.",
    "Agent orchestration: jobs rendered from the work graph at dispatch, and completion decided by a function over evidence in the database."
   ]
  },
  {
   "url": "https://coreyjames.ai/ideas/disconnected-producers-and-consumers/",
   "kind": "idea",
   "title": "Disconnected producers and consumers",
   "subtitle": "Nothing waits on anything else: the method under most of my high-throughput work",
   "systems": [
    "inference-fabric",
    "fafo-core",
    "fafohive",
    "agent-swarm"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "163K",
     "label": "tokens per second, five-minute mean on two cards, from about 44,000"
    },
    {
     "value": "3",
     "label": "batching modes any Function Forge function can run in by configuration"
    }
   ],
   "lede": "Most pipelines are built as request and response: the thing that wants work done waits for the thing that does it. That coupling is why GPUs sit idle while a producer formats the next request, why a slow database stalls generation, and why a crash in one process takes the others down with it. I build the opposite shape wherever throughput or resilience matters. Producers submit work to a durable queue and exit. Consumers pull from the queue at their own pace. A separate completion path lands results where they belong. No component ever waits on another, and every component restarts on its own. The shape A producer's job ends the moment its work is durably stored. It does not",
   "quote": "I cut at the point where the two sides have different natural rates: producers that are bursty and cheap, consumers that are expensive and steady.",
   "evidence": [
    "High-throughput batch inference: producers that submit and exit, a durable queue, pull-based GPU consumers and a separate completion path, the shape behind 163K tokens per second from about 44,000.",
    "Message broker and queue design: backpressure by not pulling, local restarts, and one definition of done, an item complete only when its completion is acknowledged.",
    "Asynchronous execution design: decoupled submit-and-exit as one of 3 batching modes any Function Forge function can run in by configuration."
   ]
  },
  {
   "url": "https://coreyjames.ai/ideas/identity-from-the-caller/",
   "kind": "idea",
   "title": "Identity from the caller, credentials on the server",
   "subtitle": "An agent is who it authenticated as, never who it says it is, and it never holds a key it does not need",
   "systems": [
    "fafohive",
    "helix",
    "agent-swarm",
    "auth-and-access-plane"
   ],
   "technologies": [],
   "stats": [],
   "lede": "The confused-deputy problem is the standing failure of agent systems: an agent acting for one principal is talked into acting for another, or holds a credential that leaks into a transcript. I remove it by construction. Identity is derived from how a caller authenticated, never from an argument in a tool call. Credentials for external services live on the server side of a gateway, are minted per identity where the platform allows it, and are never handed to a model. The shape A gateway between agents and the outside world authenticates the agent, derives its assignment or employee identity from that authentication, and performs the external call itself with credentials it holds. Attribution is written into the external payload only",
   "quote": "Anything that works by trusting what an agent says about itself is a design that has not failed yet.",
   "evidence": [
    "Identity and least privilege for AI agents: identity derived on the server from how an agent authenticated, never from an argument in a tool call.",
    "Credential brokering and secrets management: external credentials held behind a gateway and minted per identity on the server, never handed to a model, with the repository credential held by a gatekeeper agent.",
    "Digital-employee identity: every meeting action names the digital employee it acts for, with employee tokens minted on the server."
   ]
  },
  {
   "url": "https://coreyjames.ai/ideas/measure-the-instrument/",
   "kind": "idea",
   "title": "Measure the instrument",
   "subtitle": "A result is only as good as the proof that the measurement measured the thing",
   "systems": [
    "activekv",
    "capabilities-model",
    "inference-fabric",
    "agentos"
   ],
   "technologies": [],
   "stats": [],
   "lede": "Every performance programme I have run has produced at least one result that was really a property of the measurement. A profiler that serialised the copy engine it was observing. A test suite that passed a thousand trials against the wrong code. A benchmark whose baseline had a stall bug. A headline that beat a weak comparison. I treat the instrument as part of the experiment, and I do not act on a number until I know what the instrument did to it. The shape Every instrumented run has an uninstrumented control. Every evaluation set is frozen before the model sees it and carries known-answer controls that can catch the team as readily as the model. Every \"switched\" claim about",
   "quote": "The instinct to protect is the instinct to believe a number that agrees with you.",
   "evidence": [
    "Performance benchmarking methodology: an uninstrumented control for every instrumented run, the strongest baseline I could build, and a profiler verdict retracted when the profiler caused the serialisation.",
    "Numerical reproducibility and bitwise validation: parity gates bitwise only where the reference agrees with itself across two runs, judged within its own spread elsewhere.",
    "Evaluation design for ML: evaluation sets frozen before the model sees them, with known-answer controls, and a classical retriever that tied the model published as the result."
   ]
  },
  {
   "url": "https://coreyjames.ai/ideas/reconcile-never-resubmit/",
   "kind": "idea",
   "title": "Reconcile, never resubmit",
   "subtitle": "When a side effect may or may not have happened, write down the uncertainty and check reality before doing anything again",
   "systems": [
    "inference-fabric",
    "fafohive",
    "agentos",
    "helix"
   ],
   "technologies": [],
   "stats": [],
   "lede": "A crash between making a call and logging it is the oldest problem in distributed systems, and the default answer, retry, is how you charge a customer twice, post the same message three times, or run the same inference on two GPUs. My systems do not retry blindly. They mark an effect as uncertain, reconcile against the real state, and resubmit only what is proven missing, under the same identity. The shape Before an effect, a durable entry for the intent. After the effect, a durable entry for the outcome. If the process dies between the two, the entry is in an explicit uncertain state, and recovery reads reality, the provider, the GPU worker, the receiver, before deciding. Nothing is",
   "quote": "An external effect that cannot be confirmed is not something a retry loop should decide on its own.",
   "evidence": [
    "Exactly-once delivery and crash recovery: intent recorded before every external effect and its outcome after, with interrupted effects held uncertain and reconciled against reality.",
    "Idempotent side effects and reconciliation: resubmission only of what is proven missing, under the same identity, and unverifiable sends held for an operator.",
    "Distributed systems correctness: a reconnecting GPU worker reports the work it holds before anything new is dispatched, so surviving work is never sent twice."
   ]
  },
  {
   "url": "https://coreyjames.ai/ideas/role-contracts-not-vendors/",
   "kind": "idea",
   "title": "Role contracts, with vendors as data",
   "subtitle": "Work is assigned to a role with a contract; which model fills the seat is configuration, and reviewers can be a different vendor from builders on purpose",
   "systems": [
    "agentos",
    "agent-swarm",
    "helix"
   ],
   "technologies": [],
   "stats": [],
   "lede": "Every model vendor would like to be the system. I treat them as workers. A job in my platform is addressed to a role with a contract: what it receives, what it must return, what it may touch, how much it may spend. Which model fills that seat, at what reasoning effort, under which account, is per-seat data. The same role can be filled by a frontier model through its subscription command-line tool, by an API seat, by a local open-source model on my own GPUs, or by a swarm job, and the contract does not change. The shape A role contract names inputs, outputs, tool classes and budget. A runtime adapter drives whichever vendor sits behind it through that",
   "quote": "The contract is the product and the vendor is a supplier.",
   "evidence": [
    "Model-agnostic agent architecture: jobs addressed to role contracts naming inputs, outputs, tool classes and budget, with model, reasoning effort and account as per-seat data.",
    "Separation of duties for AI work: builders on one model family and quality and adversarial reviewers on another, so their blind spots do not overlap.",
    "Agent orchestration: subscription command-line tools, API seats, local open-source models and swarm jobs filling the same role, behind a terms-of-service firewall."
   ]
  },
  {
   "url": "https://coreyjames.ai/ideas/separate-planes-by-role/",
   "kind": "idea",
   "title": "Separate planes by role",
   "subtitle": "Traffic with different reliability, latency and durability needs gets its own infrastructure, so pressure in one role cannot starve or corrupt another",
   "systems": [
    "agent-swarm",
    "fafo-core",
    "auth-and-access-plane",
    "inference-fabric"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "6",
     "label": "leakage rules between the delivery, coordination and durability planes"
    },
    {
     "value": "100 ms",
     "label": "budget on the live-control stream, kept apart from the command stream"
    }
   ],
   "lede": "One Redis would do. One queue would do. One tunnel would do. I run several of each, because the roles that share them have different needs, and the first time a bulk job starves a control message or a cache eviction silently drops a write you learn why. Delivery, coordination and durability are separate planes with explicit rules about what may cross between them, and infrastructure is sized and configured per role. The shape Name the roles: a job queue, a write-behind queue, a control stream, a coordination bus, a durability store. Give each the configuration its role needs, eviction or no eviction, append-only persistence or not, a tight latency budget or a throughput budget. Put a rule at every",
   "quote": "A failure in one plane is a failure in one plane.",
   "evidence": [
    "Distributed systems isolation: delivery, coordination and durability planes with 6 leakage rules between them, so pressure in one role cannot starve another.",
    "Redis architecture per role: separate instances for a job queue, a write-behind queue with no eviction, GPU job control and a coordination bus.",
    "Control-plane design: a live-control stream with a 100 ms budget kept apart from the command stream, and main and bulk write lanes."
   ]
  },
  {
   "url": "https://coreyjames.ai/ideas/the-copy-of-record-lives-off-the-accelerator/",
   "kind": "idea",
   "title": "The copy of record lives off the accelerator",
   "subtitle": "Host memory or the database holds the truth; the GPU or the model holds a bounded working set",
   "systems": [
    "activekv",
    "inference-fabric",
    "agentos",
    "fafohive"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "27B",
     "label": "parameter model whose attention history lives in host RAM"
    },
    {
     "value": "32 GB",
     "label": "one card holding only the working set"
    },
    {
     "value": "128K",
     "label": "token histories served from that card"
    }
   ],
   "lede": "The expensive resource in every system I build, GPU memory or a model's context window, is also the least durable and the hardest to reason about. So I never let it hold the truth. The copy of record lives somewhere cheap, durable and inspectable: pinned host memory, a PostgreSQL work graph, an append-only log, a parsed code graph. The accelerator holds a bounded working set that is staged in, used, and written back under an explicit budget. The shape The authoritative state is written where it can be large and survive restarts. The working set is sized by a stated budget, filled from the copy of record on demand, and released on a fence or a step boundary. design <figure",
   "quote": "An automatic size hides the operator's choice, and a silent degradation hides the failure.",
   "evidence": [
    "KV-cache offload for LLM inference: attention history for a 27B model held in pinned host RAM and staged per layer, serving 128K-token histories on one 32 GB card.",
    "GPU memory management: staging buffers reused only after every copy and kernel reading them has finished, refusing or shrinking rather than degrading when the working set cannot fit.",
    "Agent state management: the work graph as the copy of record and the model's context as a working set rendered at dispatch and rebuilt after a crash."
   ]
  },
  {
   "url": "https://coreyjames.ai/ideas/the-token-as-the-unit/",
   "kind": "idea",
   "title": "The token as the unit",
   "subtitle": "Schedule, budget and account for GPU work in the unit the hardware actually pays in",
   "systems": [
    "inference-fabric",
    "fafo-core",
    "activekv",
    "capabilities-model"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "0.42%",
     "label": "padding waste across two NVIDIA Blackwell GPUs"
    },
    {
     "value": "99.9%",
     "label": "cache hit rate on the same pair"
    },
    {
     "value": "12.3 B",
     "label": "tokens received, balanced against the same number routed"
    }
   ],
   "lede": "Queues move messages. Schedulers count jobs. Budgets count dollars or requests. None of those is what a GPU pays in. A GPU pays in tokens, and its cost for a batch depends on the shape of those tokens: how long each sequence is, how much of each prefix is shared with its neighbours, how much padding the batch carries, whether the cache already holds the work. Once I made the token the unit of scheduling, packing, budgeting and accounting, a whole class of inefficiency became visible and fixable. The shape Work is described to the scheduler by its token geometry. Batches are packed to a consumer's declared token limits, not to a count of items. design <figure class=\"dv-figure\" aria-label=\"A batch",
   "quote": "The broker must not know the model; it must know only what the consumer needs to pack well, and four integers turn out to be enough.",
   "evidence": [
    "Token-aware scheduling: shape-pure batches packed to each consumer's declared token limits, with 0.42% padding waste and a 99.9% cache hit rate across two NVIDIA Blackwell GPUs.",
    "Distributed systems correctness: token accounting that balanced 12.3 B tokens received against the same number routed."
   ]
  },
  {
   "url": "https://coreyjames.ai/ideas/tools-are-the-platform/",
   "kind": "idea",
   "title": "Tools are the platform",
   "subtitle": "Build the safety machinery once, make it the only path, and let everything else be a declaration",
   "systems": [
    "agent-swarm",
    "fafo-core",
    "fafohive",
    "capabilities-model"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "474",
     "label": "tools behind one authenticated FAFOHive endpoint, under one trust model"
    },
    {
     "value": "12",
     "label": "steps in the frozen pipeline every Agent Swarm call passes"
    },
    {
     "value": "~180",
     "label": "gateway actions compiled from YAML schemas into dispatch"
    }
   ],
   "lede": "An agent is only as capable as the tools it can reach and only as safe as the path those tools take. I decided that the path would be built once, that it would be the only path, and that adding capability would be a matter of declaring a tool rather than writing a service. Validation, authorisation, limits, sanitisation, audit and observation happen in one pipeline for every call. A tool contributes its core behaviour and nothing else. An agent class is a composition of a tool subset, a policy, a workspace and a profile. The shape One frozen pipeline in a fixed order. Tools declared as data. Composition is declarative: a persona is a document, a function is a",
   "quote": "Exceptions are where the holes are.",
   "evidence": [
    "Tool synthesis and governed API integration: one frozen pipeline of 12 steps for every call, with tools declared as data and compiled into dispatch so a tool is fully wired or the build fails.",
    "MCP server design: 474 tools behind one authenticated endpoint under one trust model, and ~180 gateway actions compiled from YAML schemas.",
    "Declarative agent definition: tools and personas defined as declarations, with hash-pinned catalogs so every host runs the same approved set."
   ]
  },
  {
   "url": "https://coreyjames.ai/tools/agent365/",
   "kind": "tool-group",
   "title": "Agent365",
   "subtitle": "",
   "systems": [
    "helix",
    "fafohive"
   ],
   "technologies": [],
   "stats": [],
   "lede": "My digital employees work inside Microsoft Teams as colleagues with their own identities, and an AI model needs tools to do that: join the meeting, speak up in chat, raise a hand, put a deck on screen, write a document and remember what was decided. This server gives it those tools. Every action names the exact digital employee it acts as, and the server resolves that employee's identity itself. Microsoft stays the authority on what the employee may do, so the server adds capability without adding a second permission system. The employees and their voice are described on the Helix page, and a self-hosted colleague in a Teams call tells the story. Identity agent365 employees lists the digital employees with",
   "quote": "",
   "evidence": [
    "Microsoft Teams agent tooling: 24 tools that let a digital employee join a Teams meeting as its own participant, speak in chat, present a deck, write documents and remember decisions.",
    "Identity for AI agents in Microsoft 365: every action names the exact digital employee it acts as, the server resolves its Entra identity, and Microsoft stays the authority on what it may do."
   ],
   "tool_count": 24
  },
  {
   "url": "https://coreyjames.ai/tools/agentos/",
   "kind": "tool-group",
   "title": "AgentOS work tools",
   "subtitle": "",
   "systems": [
    "agentos",
    "agent-swarm",
    "fafohive"
   ],
   "technologies": [],
   "stats": [],
   "lede": "AgentOS runs teams of AI agents against governed work orders, and the agents in those teams need a way to act inside that governance without being able to bend it. I gave them a deliberately narrow set of tools. The caller's identity fixes which work order, team and role it is acting for, so an agent cannot name a different work order or claim a different seat. Most actions take the path of a file the agent has written, so large plans and reviews stay on disk and the tool call stays small. Many of the tools answer with a receipt and deliver the final outcome to the team lead's mailbox, because the work they start keeps going after the",
   "quote": "",
   "evidence": [
    "Agent orchestration tools: 11 tools that let governed agents author, validate and start work orders and act inside their team without being able to name another work order or seat.",
    "Identity-scoped agent actions: the caller's identity fixes its work order, team and role; actions take file paths and return receipts, with outcomes delivered to the team lead's mailbox."
   ],
   "tool_count": 11
  },
  {
   "url": "https://coreyjames.ai/tools/email-and-crm/",
   "kind": "tool-group",
   "title": "Email and CRM provider",
   "subtitle": "",
   "systems": [
    "fafohive"
   ],
   "technologies": [],
   "stats": [],
   "lede": "A business run by agents needs email, a contact database and a sales pipeline from day one, and the email/CRM provider's API covers nearly three hundred operations. I rebuilt every one of them as a tool of my own behind my gateway. Around them I built the path: identity checks on every caller, the work order worked out from that identity, a durable record of every call, and inbound events routed back to the right team. The provider's credentials never leave my server. This provider does not support stamping work-order tags onto what it creates, so the gateway attributes its calls in its own accounting and leaves the provider's objects untouched. What the group covers Loyalty programs, 50 tools. Agents",
   "quote": "",
   "evidence": [
    "Governed API integration for AI agents: 291 tools rebuilt from an email and CRM provider's API, letting agent teams run campaigns, transactional messages, contacts, deals and loyalty programs.",
    "Credential isolation and attribution: provider credentials never leave my server, every call is recorded and attributed in my own accounting, and inbound events reach the team that caused them."
   ],
   "tool_count": 291
  },
  {
   "url": "https://coreyjames.ai/tools/facebook/",
   "kind": "tool-group",
   "title": "Facebook Page provider",
   "subtitle": "",
   "systems": [
    "fafohive"
   ],
   "technologies": [],
   "stats": [],
   "lede": "A business's Facebook Page is its storefront, and an agent that runs one has to cover the whole life of a post: publish it, answer the comments, handle the messages, measure it and clean up after it. I built this provider as my own MCP server over the Meta Graph API. It keeps its own register of everything it created, so delete tools only ever touch the Page's own posts, media and comments. Writes are read back before they are reported. Incoming comments, messages, mentions and reviews are collected into a local inbox, and Graph usage and permission health are visible to the agent before it hits a limit. Posts and publishing fb publish post publishes a Page post as",
   "quote": "",
   "evidence": [
    "Social platform integration: 24 tools on my own MCP server over the Meta Graph API let an agent publish, schedule, edit and measure Page posts and answer comments and messages.",
    "Safe automation design: a register of everything the provider created limits deletes to the Page's own content, writes are read back before they are reported, and Graph usage is visible before a limit is hit."
   ],
   "tool_count": 24
  },
  {
   "url": "https://coreyjames.ai/tools/fafodev/",
   "kind": "tool-group",
   "title": "FAFODev",
   "subtitle": "",
   "systems": [
    "fafo-core",
    "inference-fabric",
    "agent-swarm",
    "fafohive"
   ],
   "technologies": [],
   "stats": [],
   "lede": "FAFODev is the server I use to build and operate FAFO Core and the Inference Fabric through an AI assistant. I made a deliberate choice about its shape: one tool per subsystem, with an action argument that selects the operation. Eighteen tools carry 171 actions. An assistant only has to learn eighteen names, each tool returns its own documentation on request, and every subsystem's operations live in one place with one schema. Many of these tools are Core functions themselves, built with the function generator below, so the platform is operated through its own machinery. Tools that build tools under governance tells the generator's story. Jobs, containers and GPUs control plane management operates the control plane that runs every Core",
   "quote": "",
   "evidence": [
    "Platform operations through an AI assistant: 18 tools with 171 actions let an assistant run jobs, containers and GPUs, control functions in flight and operate the inference fabric.",
    "MCP server design: one tool per subsystem with an action argument and self-documentation, many of them functions built by the platform's own generator."
   ],
   "tool_count": 18
  },
  {
   "url": "https://coreyjames.ai/tools/media/",
   "kind": "tool-group",
   "title": "Media and image generation",
   "subtitle": "",
   "systems": [
    "fafohive",
    "helix"
   ],
   "technologies": [],
   "stats": [],
   "lede": "I wanted any agent in my estate to be able to make images, video and narration on my own GPUs, without anyone hand-starting a ComfyUI server or copying files between machines. The hard parts are around the rendering: a GPU is shared with other work, model files are large, a render can finish while its delivery fails, and an agent that retries blindly burns GPU time on work it already did. So these 33 tools treat every step as a durable operation with its own identifier. Starting a service goes through the compute budget. Model downloads are planned before they run and checked after. A render and its delivery are tracked separately, so a failed copy is repeated without rendering",
   "quote": "",
   "evidence": [
    "GPU media generation for AI agents: 33 tools let an agent start a managed ComfyUI service on a chosen GPU, plan model downloads, render images and video and produce narration.",
    "Durable operations design: every step has its own identifier, starts go through the compute budget, and a render is tracked apart from its delivery so a failed copy never re-renders."
   ],
   "tool_count": 33
  },
  {
   "url": "https://coreyjames.ai/tools/memory-and-code-search/",
   "kind": "tool-group",
   "title": "Memory and code search",
   "subtitle": "",
   "systems": [
    "fafohive"
   ],
   "technologies": [],
   "stats": [],
   "lede": "Agents waste most of their effort rediscovering things: where a behaviour lives in the code, why a decision was made, what went wrong last week. I gave every agent in my estate the same memory, served by FAFOHive. These eight tools are how an agent asks it questions. Code is indexed by syntax tree, so a search returns whole functions and types with file and line. The code graph answers structural questions without a model. Decisions and fixes are kept as observations, so the reasoning behind a change outlives the session that made it. The tools list indexes lists the code and reference collections that exist and how much each holds. Its names are the scope every search uses. search",
   "quote": "",
   "evidence": [
    "Memory for AI agents: 8 tools let an agent search code by syntax tree, search reference material, recall past decisions and fixes, and record new observations.",
    "Code intelligence for AI agents: code-graph tools answer callers, callees and dependency questions without a model, returning file paths and lines."
   ],
   "tool_count": 8
  },
  {
   "url": "https://coreyjames.ai/tools/payments/",
   "kind": "tool-group",
   "title": "Payments provider",
   "subtitle": "",
   "systems": [
    "fafohive"
   ],
   "technologies": [],
   "stats": [],
   "lede": "Agent teams that build businesses need to create products and prices, take payments and read what happened. I rebuilt the provider's API as nine tools of my own and put my gateway in front of them, so the agents get the provider's capability while its keys stay on my server. The gateway is mine too: it accepts calls only from authenticated agent seats, works out the work order from the caller's identity, records every call before it reaches the provider, tags newly created objects with the work order where the provider supports it, and routes the provider's webhooks back to the team that caused them. Agents with real tools and no keys tells how that came together. What the group",
   "quote": "",
   "evidence": [
    "Payments integration for AI agents: 9 tools rebuilt from a payments provider's API let agent teams create products and prices, take payments and read account activity.",
    "Governed API integration: callers authenticated as agent seats, work orders derived from identity, every call recorded before it reaches the provider, and webhooks routed back to the team that caused them."
   ],
   "tool_count": 9
  },
  {
   "url": "https://coreyjames.ai/tools/provider-routing/",
   "kind": "tool-group",
   "title": "Provider routing",
   "subtitle": "",
   "systems": [
    "fafohive",
    "agentos"
   ],
   "technologies": [],
   "stats": [],
   "lede": "When an agent team builds a business, the providers that business uses start talking back: a customer pays, an email is answered, a post gets a comment. Those events have to reach the team that caused them, and a website the team deploys has to call the providers under that team's name. I built three small tools for that wiring. None of them takes a work order as input. The work order, its team lead and its execution come from the caller's identity, so an agent can only wire its own work. The tools register provider inbox sends the provider events that belong to the current work order to its team lead's mailbox. create website runtime binding binds a deployed",
   "quote": "",
   "evidence": [
    "Event routing for agent teams: 3 tools wire a work order's provider events to its team lead's mailbox, bind the team's website to its provider connections, and route inbound email to the team.",
    "Identity-derived authorization: none of the tools takes a work order as input; the work order comes from the caller's identity, so an agent can only wire its own work."
   ],
   "tool_count": 3
  },
  {
   "url": "https://coreyjames.ai/tools/reddit/",
   "kind": "tool-group",
   "title": "Reddit provider",
   "subtitle": "",
   "systems": [
    "fafohive"
   ],
   "technologies": [],
   "stats": [],
   "lede": "I wanted agents to take part in Reddit threads from an account a person already uses, and I was not willing to copy that person's session or credentials into a server. So the Reddit provider runs inside the browser that is already logged in. A browser extension makes the same requests Reddit's own page would make, and a small native host connects it to the FAFOHive hub over a private local socket. There are no clicks, no navigation and no login. Every write checks first that the session belongs to the expected account, and is read back afterwards until the exact result is confirmed. Each write carries an idempotency key, so a retry cannot post twice. The tools reddit identity",
   "quote": "",
   "evidence": [
    "Browser-based platform integration: 6 tools let an agent read Reddit threads and comments and post or edit its own comments from an account a person already uses, with no copied credentials.",
    "Safe automation design: every write checks the session's account first, is read back until the exact result is confirmed, and carries an idempotency key so a retry cannot post twice."
   ],
   "tool_count": 6
  },
  {
   "url": "https://coreyjames.ai/tools/social-publishing/",
   "kind": "tool-group",
   "title": "Social-publishing provider",
   "subtitle": "",
   "systems": [
    "fafohive"
   ],
   "technologies": [],
   "stats": [],
   "lede": "For the networks where I have not built my own provider, agent teams publish through a social-publishing provider that reaches many platforms from one account. As with the payments and email/CRM groups, the 54 tools are rebuilt from the provider's API and the gateway around them is mine: callers are authenticated agent seats, each call is attributed to the work order behind it and recorded before it goes out, created posts carry that attribution where the provider supports it, and the provider's events come back to the right team. For X, Facebook and Reddit I built my own providers, described on the X, Facebook and Reddit pages. What the group covers Posts and publishing, 13 tools. Agents create, edit, cross-post,",
   "quote": "",
   "evidence": [
    "Social media automation for AI agents: 54 tools rebuilt from a social-publishing provider's API let agent teams publish, schedule, cross-post and measure posts across many networks.",
    "Governed API integration: every call attributed to the work order behind it and recorded before it goes out, with the provider's events returned to the right team."
   ],
   "tool_count": 54
  },
  {
   "url": "https://coreyjames.ai/tools/x/",
   "kind": "tool-group",
   "title": "X provider",
   "subtitle": "",
   "systems": [
    "fafohive"
   ],
   "technologies": [],
   "stats": [],
   "lede": "I needed agents that could research conversations on X and take part in them, and the existing options did not fit. X's official API covers only some of what a campaign needs, research reads are metered, and a social account is easy to damage with careless automation. So I built my own X provider as two MCP servers behind the FAFOHive hub. One holds 21 tools that research, read and report. The other holds 15 tools that act on the account, and it is authorised separately, so an agent can be given research without being given the account. Underneath is a hybrid backend: a commercial X data API for public research, the official X API for account operations and activity",
   "quote": "",
   "evidence": [
    "Social research and engagement for AI agents: 36 tools on two MCP servers, 21 that research, read and report on X conversations and 15 that act on the account.",
    "Least privilege for AI agents: the acting server is authorised separately, so an agent can be given research without being given the account.",
    "Hybrid API integration: a data API for research, the official API for account operations and webhooks, and a browser bridge for the rest, with every write read back before it is reported."
   ],
   "tool_count": 36
  },
  {
   "url": "https://coreyjames.ai/technologies/acme/",
   "kind": "technology",
   "title": "ACME",
   "subtitle": "Automated certificate issuance keeps my services' TLS current without a human in the loop, in the agent runtime and the access plane.",
   "systems": [
    "auth-and-access-plane",
    "agent-swarm"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "46",
     "label": "lines of Python in the HTTP-01 challenge responder"
    },
    {
     "value": "2",
     "label": "challenge types, picked per surface"
    },
    {
     "value": "2",
     "label": "issuance backends behind one interface"
    }
   ],
   "lede": "Renewing the web fronts without me Auth and access plane serves an OAuth authorization server, MCP gateways and webhook intake to the internet from an estate with no open inbound ports. Every one of those surfaces sits behind an NGINX TLS front, and I wanted each certificate to renew without me. I chose ACME's HTTP-01 challenge for the web fronts, where a proxy already answers on port 80, and answered it on the same proxy path that carries real traffic. design <figure class=\"dv-figure\" aria-label=\"HTTP-01 answered on the path real traffic takes\" <span class=\"eyebrow\" style=\"margin-top: 0\" Real traffic</span <div style=\"display: flex; gap: 2px; min-height: 30px; border-radius: 8px; overflow: hidden; margin-top: 0.7rem\" <div style=\"flex: 1; background: var(--rule); display: flex; align-items: center; padding:",
   "quote": "I treat certificate issuance as part of the platform.",
   "evidence": [
    "TLS certificate automation: ACME issuance for web fronts and agent containers with no person in the loop, HTTP-01 answered by a 46-line responder on the path real traffic takes.",
    "Rust systems engineering: DNS-01 certificate minting written into the agent runtime as Rust crates, two issuance backends behind one interface, challenge records removed on every exit path.",
    "Secrets hygiene in container platforms: certificates mounted into containers at launch and never baked into an image, so rebuilding an image can never ship a key."
   ],
   "technology_kind": "protocol"
  },
  {
   "url": "https://coreyjames.ai/technologies/admission-control-and-rate-limiting/",
   "kind": "technology",
   "title": "Admission control and rate limiting",
   "subtitle": "Every surface I expose has a stated limit and a typed refusal.",
   "systems": [
    "fafo-core",
    "postgresql-fabric",
    "fafohive",
    "capabilities-model"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "3 modes",
     "label": "for every admission limit, so a new one is watched before it refuses"
    },
    {
     "value": "3",
     "label": "processes, agent calls, a scheduler and a poller, on one account-wide X limit"
    },
    {
     "value": "60%",
     "label": "platform usage past which the Facebook poller skips its run"
    },
    {
     "value": "0",
     "label": "daily caps of my own on the social modules"
    }
   ],
   "lede": "I built admission control into the memory service, the execution substrate's admission controller and a GPU decoder that refuses with a number rather than queueing silently. I decide where a limit sits by asking what the protected resource actually runs out of. Pricing database work by its cost FAFO Core and Function Forge lets agents call database-heavy functions over MCP, and agents submit as much work as you let them. The database has a fixed number of connections, a fixed write budget and fixed I/O, and the operations behind those functions range from zero-write reads to rewrites of a whole vector lattice. One request-per-second limit cannot fit that range. I priced every request by its expected cost to the database,",
   "quote": "A refusal carries a type and a number the caller can act on; a silent queue or a timeout gives the caller nothing.",
   "evidence": [
    "Database admission control: a Rust admission service that prices each request by its expected cost to the database, so heavy rewrites wait and cheap reads flow, with off, shadow and enforcing modes.",
    "Rate limiting for third-party APIs: Redis buckets on the server's clock, reads refused when a rolling budget is spent and writes paced, never rejected; one service owning a limit shared by 3 processes.",
    "API quota sharing: a Facebook module that returns the platform's usage headers with every tool result and skips background polls past 60 percent usage, leaving room for agents.",
    "Backpressure with typed refusal: a GPU tool-discovery decoder that admits work against measured free memory beside a serving model and answers a full engine with a typed busy response and a retry hint."
   ],
   "technology_kind": "discipline"
  },
  {
   "url": "https://coreyjames.ai/technologies/agent-client-protocol-acp/",
   "kind": "technology",
   "title": "Agent Client Protocol (ACP)",
   "subtitle": "I built agents that speak the Agent Client Protocol so coding assistants can be driven as governed workers rather than chat windows.",
   "systems": [
    "agentos",
    "agent-swarm"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "25",
     "label": "hard ceiling on delegation depth; a persona configured deeper is refused"
    },
    {
     "value": "4",
     "label": "checks on every receipt: audience, issuer, hash and call chain"
    },
    {
     "value": "2",
     "label": "transports for the same envelopes: stdio and Redis streams"
    },
    {
     "value": "7",
     "label": "typed endings in the delivery adapter besides acceptance"
    }
   ],
   "lede": "ACP is the seam between my governance platform and the vendors' own tools. A signed wire for agents that delegate to agents Agent Swarm lets agents delegate to one another, and a receiving agent has to know who really sent a request, on whose behalf, and that the chain of delegation is not looping or growing without end. I did not want a home-grown protocol for that. I adopted the Agent Client Protocol, which is JSON-RPC 2.0, as the cross-vendor agent protocol and locked the choice into the runtime's master plan; I did not author ACP, I use it and extend it. ACP runs over stdio for agents started as subprocesses; between long-lived agents the same envelopes travel on Redis",
   "quote": "I put identity and delegation limits into the wire itself.",
   "evidence": [
    "Agent-to-agent protocol design: the Agent Client Protocol adopted as the cross-vendor wire and extended with canonical hashing and RS256-signed envelopes, keeping the base protocol standard.",
    "Multi-agent governance: bounded delegation enforced on every receipt with 4 checks (audience, issuer, hash and call chain) and a hard depth ceiling of 25 that no persona can raise.",
    "Agent orchestration: a delivery adapter that drives a vendor's own coding tool through its supported ACP bridge and counts a prompt accepted only on the vendor's own acknowledgement, with 7 typed endings."
   ],
   "technology_kind": "protocol"
  },
  {
   "url": "https://coreyjames.ai/technologies/agent-tool-execution-safety-and-sandboxing/",
   "kind": "technology",
   "title": "Agent tool-execution safety and sandboxing",
   "subtitle": "Every action any agent takes in my runtime passes one frozen pipeline: validation, authorisation, limits, sanitisation, audit, observation.",
   "systems": [
    "agent-swarm"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "12 steps",
     "label": "every tool call passes, in a fixed order"
    },
    {
     "value": "22,600",
     "label": "lines in the tools module, with its schema validator, tool kinds and built-ins"
    },
    {
     "value": "0",
     "label": "commits by the coding agent straight to the main repository; the gatekeeper opens the merge"
    }
   ],
   "lede": "I make the safe path the only path, and I take flexibility away where flexibility would let an action skip a check. One frozen path for every tool call Agent Swarm runs agents that act on real systems. If every tool does its own validation, permission checks and logging, each new tool is a new place for a mistake, and nobody can audit a fleet of them. I decided there would be exactly one path for an action and that the path would be frozen. Every tool call, of every kind, goes through one Rust harness in a fixed order, and a tool marked as needing approval pauses the agent loop until approval arrives. design <figure class=\"dv-figure\" aria-label=\"The twelve steps",
   "quote": "A configurable pipeline is more flexible; a fixed one is something I can trust, because there is one way an action happens.",
   "evidence": [
    "Agent tool governance: every tool call of every kind through one Rust harness of 12 steps in a fixed order, a new tool supplying only its execute body, in a tools module of about 22,600 lines.",
    "Sandboxing and container hardening: each agent persona launched as a Docker container with CPU, memory, process, runtime and egress caps, a turn budget and its own workspace.",
    "Injection defence for agent tools: shell templates with typed parameter classes and an attack fixture beside every golden fixture, and HTTP templates encoded per RFC 3986.",
    "Separation of duties for AI work: a coding agent that edited, tested and pushed on its own branch and asked a gatekeeper agent to open the merge request, with 0 commits to the main repository."
   ],
   "technology_kind": "discipline"
  },
  {
   "url": "https://coreyjames.ai/technologies/agent-tool-qualification-testing/",
   "kind": "technology",
   "title": "Agent tool qualification testing",
   "subtitle": "No tool in my agent runtime ships without golden fixtures and attack fixtures, and the build fails otherwise.",
   "systems": [
    "agent-swarm",
    "fafohive"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "50",
     "label": "golden fixtures for 40 declarative tools"
    },
    {
     "value": "1,200",
     "label": "lines in the Rust test runner"
    },
    {
     "value": "3",
     "label": "platform-semantics defects the Facebook proof found, each now a test"
    }
   ],
   "lede": "The same standard governs the social integrations: every write read back, every create with a delete, every inbound item an event. I set acceptance rules that turn \"it works\" into counted cases and side-channel measurements, and I make the build enforce them. Fixtures that fail the build Agent Swarm adds tools as YAML declarations, and I knew a tool nobody tests is the hole an agent eventually finds. So a tool without fixtures fails the build, and attack fixtures are required even for one-line tools, because exceptions to a safety rule are where the holes appear. The test runner is a Rust crate that loads the catalog with the same loader the runtime uses, registers the built-in and declarative tools,",
   "quote": "A write whose outcome is uncertain is reconciled and cleaned up, and never resent, because on a social platform a duplicate does more harm than a gap.",
   "evidence": [
    "Test engineering for AI agent tools: a Rust runner that sends every fixture through the real invocation harness, 50 golden fixtures for 40 declarative tools, and a build that fails on a tool without fixtures.",
    "API qualification by parameter class: an X module qualified across 35 tools and 203 parameters with 1,010 calls and 872 asserted cases, then 505 invocations against the metered API.",
    "Side-channel measurement in integration testing: a Facebook proof harness that blocked and counted every HTTP request outside a tool body and found 3 platform-semantics defects, each now a test."
   ],
   "technology_kind": "discipline"
  },
  {
   "url": "https://coreyjames.ai/technologies/append-only-log-and-journal-design/",
   "kind": "technology",
   "title": "Append-only log and journal design",
   "subtitle": "The Inference Fabric's broker is an append-only, memory-mapped log on NVMe whose unit is the token.",
   "systems": [
    "inference-fabric"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "256 MB",
     "label": "a segment rotates at this size, or when it goes idle"
    },
    {
     "value": "4 bytes",
     "label": "the in-place write that retires a work item, with no compaction"
    },
    {
     "value": "12.3B",
     "label": "tokens received and routed, a 7B dense FP8 workload on two Blackwell GPUs"
    }
   ],
   "lede": "I designed completion accounting on the broker's log so that work retires only when acknowledged, which is how a six-million-item loss was closed. I fix data loss at the definition that caused it and build recovery on one source of truth. The log is the queue Inference Fabric needed producers to drop millions of tokenised tasks and walk away while GPUs on other machines worked through them for hours. I made the broker's backlog an append-only, memory-mapped log on NVMe and made that log the only durable copy, with no write-ahead log beside it. The log is the queue, which is what lets producers submit and exit. The log is divided into segments, and each segment holds work for exactly",
   "quote": "Computation can repeat after a failure; observable completion happens once.",
   "evidence": [
    "Append-only log design: a memory-mapped log on NVMe as the broker's only durable copy, segments rotating at 256 MB, and a work item retired by a 4-byte in-place write with no compaction.",
    "Exactly-once delivery and crash recovery: recovery from deletion markers alone and two-phase dispatch that checks before it mutates, closing a six-million-item loss; 12.3B tokens received and routed.",
    "Write-ahead journalling: a vector shard store that writes its journal before the shard and accepts no connection until every mid-build shard is replayed and truncated."
   ],
   "technology_kind": "discipline"
  },
  {
   "url": "https://coreyjames.ai/technologies/application-security-hardening-and-threat-modelling/",
   "kind": "technology",
   "title": "Application security hardening and threat modelling",
   "subtitle": "I review my own public endpoints, fix findings in severity order with explicit probes, and re-run the threat model when a fix breaks the world.",
   "systems": [
    "auth-and-access-plane"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "3",
     "label": "findings from the hardening pass"
    },
    {
     "value": "7 probes",
     "label": "written beside the fixes"
    },
    {
     "value": "9,000",
     "label": "lines of Python in the security-module library"
    }
   ],
   "lede": "The OAuth registration lock I reverted within a day is the worked example. I treat security as a threat-model question: I close holes quickly, and I reverse my own fix when the facts show it sits at the wrong layer. A hardening pass, triaged by severity Auth and access plane has an OAuth authorization server that is public on purpose: commercial AI assistants self-register as clients and connect to my private tool estate through it. Its traffic analytics showed me exposure, so I ran a hardening pass. I triaged the findings by severity, applied the smallest fix for each, and paired each fix with a probe, so every fix has a test that shows it doing its job. The high",
   "quote": "A security change that locks out every legitimate client is a failed change, and I reverse it on the facts even when it looked like hardening.",
   "evidence": [
    "Application security hardening: a public OAuth authorization server's findings triaged by severity, each fixed with the smallest change and paired with one of 7 acceptance probes.",
    "Threat modelling: a fail-closed registration gate reversed when it locked out every assistant, the control kept at the consent screen and pending-client lifetime raised from 1 hour to 30 days.",
    "Defence in depth for web services: NGINX with TLS 1.2 and 1.3, HSTS and per-endpoint rate limits, a sandboxed systemd unit, and a 9,000-line Python security library kept off the request path."
   ],
   "technology_kind": "discipline"
  },
  {
   "url": "https://coreyjames.ai/technologies/applied-cryptography/",
   "kind": "technology",
   "title": "Applied cryptography",
   "subtitle": "I apply cryptography where it buys attribution and non-repudiation, and I do not invent primitives.",
   "systems": [
    "agent-swarm",
    "auth-and-access-plane",
    "fafohive",
    "helix"
   ],
   "technologies": [],
   "stats": [],
   "lede": "Signed agent-to-agent envelopes, certificate-based token minting for Microsoft identities, signed webhooks and signed event feeds. I place each check where it runs on every call, and every construction is standard, RS256, HMAC and X.509 certificate assertions from maintained libraries. Signed messages between agents Agent Swarm lets agents delegate to each other, and I wanted every request to carry proof of who sent it. I sign wherever attribution matters, so agent messages, access tokens and event feeds each carry a provable sender. Each agent-to-agent envelope is signed as a JWT with the sending agent's own key, and verification is local, which keeps signature checks off the latency path of stream messaging. The protocol around these envelopes is on the Agent Client",
   "quote": "The model asks for an action; the server holds the key.",
   "evidence": [
    "Message signing for multi-agent systems: each agent-to-agent envelope signed as an RS256 JWT with the sending agent's own key and checked locally, off the latency path of stream messaging.",
    "OAuth 2.0 and identity architecture: an authorization server signing RS256 tokens published as JWKS, and a Rust gateway validating tokens from more than one issuer offline on every call.",
    "Webhook security: an HMAC computed over the raw request body before any parsing, so a parser quirk cannot change what was signed.",
    "Credential isolation for AI agents: Graph tokens for a Microsoft 365 digital employee minted on the server from X.509 certificate assertions; the model asks for actions and never holds the key."
   ],
   "technology_kind": "discipline"
  },
  {
   "url": "https://coreyjames.ai/technologies/approximate-nearest-neighbour-search/",
   "kind": "technology",
   "title": "Approximate nearest-neighbour search",
   "subtitle": "I built exact, inverted-file and lattice nearest-neighbour search as GPU kernels with CPU references and equivalence tests, inside a vector store whose index builds are deterministic and whose search reports its own health.",
   "systems": [
    "inference-fabric"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "0.85",
     "label": "IVF recall at 10 against exact search, the floor a CI test holds"
    },
    {
     "value": "128",
     "label": "largest k; cosine, dot product and L2 are entry points in one binary"
    },
    {
     "value": "1e-4",
     "label": "relative tolerance between each GPU executor and its CPU reference"
    }
   ],
   "lede": "I write first-party GPU search when the available libraries cannot meet the platform, and I hold it to exact references and CI recall floors from the first kernel. Why I wrote the search myself Inference Fabric produced bulk embedding and hidden-state vectors that I wanted searched and analysed on the GPU where they were stored. The established GPU vector libraries gave me search and whole-dataset clustering, and could not reach the platform. I wrote the search myself: a CUDA engine driven from Rust through the raw CUDA Driver API, compiled for the NVIDIA Blackwell GPU generation. design <figure class=\"dv-figure\" aria-label=\"What each option could do on the platform, and the one kept\" <div style=\"display: grid; grid-template-columns: minmax(0, 1fr) 96px 96px; gap:",
   "quote": "Exact search is the reference that every approximate family is measured against in CI.",
   "evidence": [
    "Vector search and ANN indexes: exact, IVF-flat and lattice nearest-neighbour search as CUDA kernels driven from Rust through the Driver API, sharing one top-k engine whose ties break on position.",
    "CUDA kernel development: an exact search kernel with one block of 256 threads per query streaming 16-row tiles through shared memory and writing only the top k, for k up to 128.",
    "Numerical equivalence testing for GPU code: every executor checked against a CPU reference at a relative tolerance of 1e-4 and a CI test holding IVF recall at 10 at 0.85 against exact search.",
    "Reproducible ML pipelines: IVF index builds that are bit-reproducible, seeded on the host outside floating-point reduction and rebuildable from their hashed inputs."
   ],
   "technology_kind": "discipline"
  },
  {
   "url": "https://coreyjames.ai/technologies/axum/",
   "kind": "technology",
   "title": "Axum",
   "subtitle": "Axum is the HTTP layer under most of my Rust services: the memory gateway, the voice engine's control surface, the execution substrate's endpoints.",
   "systems": [
    "fafohive",
    "fafo-core",
    "helix",
    "agent-swarm"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "~70",
     "label": "REST endpoints in FAFOHive's API, beside its MCP transport"
    },
    {
     "value": "19,000",
     "label": "lines in that API module"
    },
    {
     "value": "1,900",
     "label": "lines in Helix's WebSocket endpoint for media frames"
    },
    {
     "value": "2 min",
     "label": "timeout for the code-path explainer, one of the per-tool limits"
    }
   ],
   "lede": "Replacing a transport that died on restart FAFOHive is one Rust process that every managed agent seat in my estate connects to, and Axum is its HTTP layer. It serves the MCP transport and a REST API. The MCP transport started on the rmcp SDK's streaming server-sent-events service, and that service broke whenever a container restarted. Container restarts are routine in my estate, so I replaced it with a per-request, TLS-terminated POST handler in Axum. design <figure class=\"dv-figure\" aria-label=\"A container restart against two transports\" <div class=\"dv-two\" <div <span class=\"eyebrow\" Streaming service · replaced</span <div class=\"dv-range\" style=\"margin-top: 1rem\" <i style=\"left: 0; width: 56%; background: var(--ink-3)\" </i <b style=\"left: 56%\" </b </div <p class=\"lbl\" style=\"margin: 0.7rem 0 0\" One long-lived stream. The",
   "quote": "My work with Axum is in transport choice, routing and middleware structure.",
   "evidence": [
    "Rust web services with Axum: the HTTP layer of an MCP server with ~70 REST endpoints in a 19,000-line API module, beside the MCP transport.",
    "MCP server design: a streaming transport that broke on container restart replaced with a per-request, TLS-terminated POST handler, with per-tool timeouts such as 2 min for the code-path explainer.",
    "API gateway design: a gateway whose MCP tool routes are generated from YAML at build time, with authentication applied as middleware per route group so new handlers inherit it."
   ],
   "technology_kind": "framework"
  },
  {
   "url": "https://coreyjames.ai/technologies/bash/",
   "kind": "technology",
   "title": "Bash",
   "subtitle": "Test harnesses, release scripts, proof runs and service glue across every system are shell.",
   "systems": [
    "activekv",
    "agentos",
    "helix",
    "fafo-core",
    "agent-swarm"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "316",
     "label": "shell scripts in ActiveKV, most of them validation and release harnesses"
    },
    {
     "value": "32",
     "label": "probes against the AgentOS work graph"
    },
    {
     "value": "11",
     "label": "checks in the integration platform's conformance suite, about 1,100 lines"
    }
   ],
   "lede": "Harnesses whose results cannot be lost ActiveKV is judged by A/B runs on a quiet host, and a harness that misreports one cell can promote a regression. The main validation driver runs a matrix of serving cells, each named by prompt length, output length and concurrency. I wanted the result impossible to lose, whatever happened to the run after the client returned. design <figure class=\"dv-figure\" aria-label=\"How one serving cell's result is written\" <div class=\"dv-two\" <div <span class=\"eyebrow\" style=\"margin-top: 0\" A matrix of serving cells · illustrative</span <div style=\"display: grid; grid-template-columns: repeat(8, 1fr); gap: 4px; max-width: 260px; margin-top: 0.7rem\" <i style=\"display: block; aspect-ratio: 1; border-radius: 4px; background: var(--tone)\" </i <i style=\"display: block; aspect-ratio: 1; border-radius: 4px; background: var(--tone)\" </i <i style=\"display:",
   "quote": "When shell hooks became policy, I ported them to Rust, because policy needs types and tests.",
   "evidence": [
    "Test harness engineering: A/B validation harnesses across 316 shell scripts whose results survive failure, cleanup and interruption, with the exit code captured first and reported by an EXIT trap.",
    "Release and provisioning automation: Microsoft 365 tenant provisioning in bash, curl and Graph that stops with a specific exit code rather than leaving a half-configured identity.",
    "Quality engineering for AI-produced work: 32 probes against the AgentOS work graph and an 11-check conformance suite of about 1,100 lines, each probe written to fail before its fix."
   ],
   "technology_kind": "language"
  },
  {
   "url": "https://coreyjames.ai/technologies/binary-wire-protocol-design/",
   "kind": "technology",
   "title": "Binary wire protocol design",
   "subtitle": "I design binary wire protocols when the problem needs them: the Teams audio link with byte-identical C# and Rust implementations, the broker's token-level transport, the vector store's RPC wire.",
   "systems": [
    "helix",
    "fafo-core",
    "inference-fabric",
    "capabilities-model"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "4",
     "label": "integers describe any GPU consumer to the broker"
    },
    {
     "value": "33",
     "label": "RPC variants on the vector store's CBOR wire"
    },
    {
     "value": "16 MiB",
     "label": "frame limit on that wire, with a streaming fetch for larger windows"
    }
   ],
   "lede": "I choose the wire per link from what the traffic costs and who has to debug it, and I prove cross-language implementations equal with golden vectors. One audio link, written twice Helix had to connect Microsoft's real-time media stack, which runs only on Windows, to my voice engine on Linux, without putting call audio in a third party's hands. I decided on a purpose-built binary link over one authenticated full-duplex WebSocket per call, implemented twice, in C# in the .NET media service and in Rust in the voice engine's endpoint. design <figure class=\"dv-figure\" aria-label=\"The same golden frame encoded by the C# and the Rust implementation, compared byte for byte\" <div style=\"display: grid; grid-template-columns: auto minmax(0, 1fr); gap: 0.5rem 0.8rem; align-items:",
   "quote": "Binary goes where the traffic is real-time audio, billions of tokens or bulk tensors; where payloads are small, a readable wire wins on diagnosability.",
   "evidence": [
    "Binary protocol design: one audio and video link for Teams calls implemented in C# and Rust and proved byte-identical against golden vectors before either carries a call.",
    "Message broker and queue design: a token-level transport where any GPU consumer is described by 4 integers and one connection carries its batches, completions and heartbeats.",
    "RPC and serialisation design: a vector store wire of 33 length-prefixed CBOR RPC variants with a 16 MiB frame limit and a streaming fetch, and a readable JSON socket where payloads are small."
   ],
   "technology_kind": "discipline"
  },
  {
   "url": "https://coreyjames.ai/technologies/budget-enforcement-and-cost-governance/",
   "kind": "technology",
   "title": "Budget enforcement and cost governance",
   "subtitle": "Spend is a first-class control in my substrate: a fail-closed daily budget on GPU provisioning that agents cannot raise from inside the provisioning path, per-second accounting, and cost attributed to the work order that spent it.",
   "systems": [
    "fafo-core",
    "inference-fabric",
    "agent-swarm",
    "helix",
    "fafohive",
    "agentos"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "$0",
     "label": "the cap on any day with no budget set"
    },
    {
     "value": "1/100 ¢",
     "label": "the precision of per-second spend accounting"
    },
    {
     "value": "10 s",
     "label": "between updates of per-container, per-schema and global spend"
    },
    {
     "value": "30 s",
     "label": "between health passes that stop paid containers at the cap"
    }
   ],
   "lede": "I build spend control into the path that spends, and I keep its key in human hands. Rented capacity and metered APIs get hard gates; model usage inside governed work gets attribution. A daily cap inside the provisioning path Agents on FAFO Core and Function Forge can stand up GPU capacity, and a rented GPU bills from power-on whether anyone remembers it or not. I decided the spending limit would live inside the provisioning path, and that its only key would be a person at a terminal. The limit is a daily dollar cap on the operator's calendar. A day runs from local midnight to local midnight in a timezone stored once, so every host computes the same day. Budgets",
   "quote": "I kept projections out of the check because an exact rule is easier to trust.",
   "evidence": [
    "Cost governance for cloud GPUs: a fail-closed daily cap checked before any port, container or cloud call, set only by a person at a terminal, and a cap of $0 on any day without a budget.",
    "Real-time spend accounting: per-second cost to a hundredth of a cent from the provider's confirmation, updated every 10 s in Redis, recomputed under a lock in Lua, paid containers stopped by a 30 s pass.",
    "API budget enforcement: units reserved before each call against a monthly budget and reconciled with the vendor's usage figures, warning at 80 percent and refusing at 100.",
    "Cost attribution for AI work: model usage split into token classes, priced against a public model-price catalog and attributed to the work order, role, persona, runtime and model that spent it."
   ],
   "technology_kind": "discipline"
  },
  {
   "url": "https://coreyjames.ai/technologies/business-provider-apis-rebuilt-as-governed-agent-tools/",
   "kind": "technology",
   "title": "Business-provider APIs rebuilt as governed agent tools",
   "subtitle": "Payments, email/CRM and social-publishing APIs, rebuilt operation by operation as governed agent tools under stable names, with credentials server-side, attribution where it round-trips and every call accounted.",
   "systems": [
    "fafohive"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "354",
     "label": "agent tools behind the FAFOHive gateway"
    },
    {
     "value": "3",
     "label": "commercial providers rebuilt as tools"
    },
    {
     "value": "0",
     "label": "provider keys in any agent's context"
    }
   ],
   "lede": "Identity, attribution and durable accounting are designed in rather than bolted on. The services belong to the providers; the tools, the gateway, the capability tables and the attribution model are mine. Every operation, a tool contract of my own FAFOHive gives managed agents a payments provider, an email/CRM provider and a social-publishing provider as tools, and I decided no agent would ever hold a provider key. The tools are mine: each provider's API was rebuilt, operation by operation, as a tool contract with a stable name, so the surface agents see is designed rather than inherited. design <figure class=\"dv-figure\" aria-label=\"Three providers' operations rebuilt as one surface of named tools\" <div style=\"display: grid; grid-template-columns: repeat(auto-fit, minmax(min(100%, 140px), 1fr)); gap: 0.9rem\" <div",
   "quote": "Unclassified operations stay usable and accounted; blocking them would break agents on every provider change.",
   "evidence": [
    "Tool synthesis and governed API integration: payments, email and CRM, and social publishing APIs rebuilt operation by operation as 354 agent tools under stable names.",
    "Identity and least privilege for AI agents: the calling assignment derived from authentication on the server, never from tool input, and 0 provider keys in any agent's context.",
    "Exactly-once delivery and crash recovery: every provider call accounted through an outbox whose replay after a restart never calls the provider twice.",
    "Data provenance and attribution: operation-level capability tables bound to each API version decide when attribution is stamped and whether an object was created or only referenced."
   ],
   "technology_kind": "discipline"
  },
  {
   "url": "https://coreyjames.ai/technologies/c-plus-plus/",
   "kind": "technology",
   "title": "C++",
   "subtitle": "ActiveKV's runtime is C++ throughout, ported from Python under bitwise-parity gates, and the Inference Fabric's TensorRT boundary is C++.",
   "systems": [
    "inference-fabric",
    "activekv"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "77,600",
     "label": "lines of non-test C++ in ActiveKV's engine, across 361 source files"
    },
    {
     "value": "568",
     "label": "test files beside them"
    },
    {
     "value": "17,900",
     "label": "lines in the per-step layer that prepares, binds, transfers and completes each step"
    },
    {
     "value": "9,500",
     "label": "lines of C++ at the Inference Fabric's TensorRT boundary"
    }
   ],
   "lede": "Porting ActiveKV's runtime out of Python ActiveKV began as Python inside vLLM. That was the right way to find out whether keeping attention history in host RAM worked, and the wrong way to ship it: the per-token path was slow, and the product logic sat in readable source. I decided to move the whole runtime to C++ with bit-identical output as the gate. design <blockquote class=\"dv-quote\" <p Every optimisation waited until parity held, because a port that changes behaviour and speed at once cannot be trusted for either.</p </blockquote The result is a C++ execution engine that loads as the vLLM plugin entry point and binds to Python through pybind11 and PyTorch's ATen. The hard problems are lifecycle problems under",
   "quote": "Every optimisation waited until parity held, because a port that changes behaviour and speed at once cannot be trusted for either.",
   "evidence": [
    "C++ and native ports with parity proof: an inference engine extension moved from Python to 77,600 lines of non-test C++ across 361 source files, with 568 test files and bit-identical output as the gate.",
    "Native memory and lifecycle engineering: fence-protected staging leases with generation counters under asynchronous DMA, a fence of unknown outcome quarantined and never reused.",
    "TensorRT and TensorRT-LLM engineering: a 9,500-line C++ layer at the TensorRT boundary that allows no device allocation after warm-up and rejects compute-stream synchronisation at run time."
   ],
   "technology_kind": "language"
  },
  {
   "url": "https://coreyjames.ai/technologies/c-sharp/",
   "kind": "technology",
   "title": "C#",
   "subtitle": "The Windows side of my Teams integration is C# on .NET 8: a media service on Microsoft's real-time SDK, screen-share publication, and a product MCP server later ported to the official .NET SDK.",
   "systems": [
    "helix",
    "auth-and-access-plane"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "6,400",
     "label": "lines of .NET 8 in the media service's six-project solution"
    },
    {
     "value": "100",
     "label": "call-to-persona bindings exercised by its unit suite"
    },
    {
     "value": "9,650",
     "label": "lines in the weather MCP server, ported to the official C# SDK"
    }
   ],
   "lede": "A narrow Windows bridge into Teams calls Helix had to put a self-hosted voice agent into Microsoft Teams calls, and Microsoft's real-time media stack runs only on Windows. design <blockquote class=\"dv-quote\" <p I keep the Windows component narrow so the system's logic stays in one place.</p </blockquote The service is .NET 8, a six-project solution covering host, calls, media, transport, contracts and unit tests, built on Microsoft's real-time media SDK and hosted on an Azure virtual machine with managed identity and vault-held secrets. It handles the calling callbacks and call lifecycle, answers inbound calls and places outbound ones, and binds each call to a persona. design <figure class=\"dv-figure\" aria-label=\"Two SDK clients composed in the calling layer\" <span class=\"eyebrow\" style=\"margin-top: 0\"",
   "quote": "I keep the Windows component narrow so the system's logic stays in one place.",
   "evidence": [
    "Microsoft Teams real-time media: a narrow .NET 8 media bridge of 6,400 lines on Microsoft's real-time media SDK that joins calls and moves frames, with all conversation state left in the Linux engine.",
    "Native interop in C#: media callbacks that copy and return at once, unmanaged audio buffers released outside the garbage collector, and a byte-identical binary protocol shared with Rust.",
    "MCP server design: a weather MCP server of 9,650 lines ported from TypeScript to the official C# SDK with the ASP.NET Core HTTP transport."
   ],
   "technology_kind": "language"
  },
  {
   "url": "https://coreyjames.ai/technologies/cache-synchronisation-and-leader-election/",
   "kind": "technology",
   "title": "Cache synchronisation and leader election",
   "subtitle": "The API integration platform keeps its cache coherent across workers and elects a leader for its sync worker.",
   "systems": [
    "fafo-core"
   ],
   "technologies": [],
   "stats": [],
   "lede": "I treat a cache that agents trust as replicated state with explicit rules for leadership, progress and deletion. FAFO Core and Function Forge has a sibling platform I designed for putting any third-party or internal API behind a governed MCP server. Each API is described by a declarative connectivity profile, and agents read from a Redis cache of that API's entities, which spares the API a call on every agent request. That makes the cache the thing agents trust, so it has to follow the source. How it was built is told in Closed by evidence. One leader per namespace Only one process may drive the sync for a namespace at a time. I chose a timer-driven singleton sync worker",
   "quote": "Eviction requires a complete view of the source; with an incomplete view the cache keeps what it has.",
   "evidence": [
    "Distributed systems correctness: a Redis cache of third-party API entities kept coherent by a delta sync whose watermark advances only when a whole cycle succeeds.",
    "Leader election: one sync worker per namespace elected through a Redis lease that expires on its own, so a dead leader's successor takes over with no operator.",
    "Cache invalidation: eviction only after a complete enumeration of the source, so a pass cut short by its read budget deletes nothing."
   ],
   "technology_kind": "discipline"
  },
  {
   "url": "https://coreyjames.ai/technologies/capacity-engineering-backpressure-and-load-testing/",
   "kind": "technology",
   "title": "Capacity engineering, backpressure and load testing",
   "subtitle": "I load-test what I build and report the misses: a 2,048-client ladder against a GPU decoder, bounded endpoints and saturating rerank in the memory service, and a pre-registered target I missed and explained.",
   "systems": [
    "fafohive",
    "capabilities-model"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "85.9",
     "label": "requests per second in a burst of 2,048 simultaneous clients"
    },
    {
     "value": "0",
     "label": "requests in that burst failed, rejected or corrupted"
    },
    {
     "value": "2,740",
     "label": "MiB, the decoder's memory budget beside a resident serving model"
    }
   ],
   "lede": "I engineer for the overloaded case first, make failure modes typed and distinct, and report capacity misses with their cause. Bounded endpoints under swarm load FAFOHive serves search to whole teams of agents at once, and under that concurrency its embedding and reranking endpoints saturate. I decided callers would never see a raw HTTP error from those endpoints, only a result or one of two typed outcomes, and I had both endpoints wrapped in a bounded-endpoint primitive to deliver that. design <figure class=\"dv-figure\" aria-label=\"A bounded endpoint: busy degrades and counts load; broken is never retried and raises an alarm\" <div class=\"dv-two\" <div <span class=\"eyebrow\" style=\"margin-top: 0; display: block\" Capacity</span <div class=\"dv-meter\" style=\"--v: 84%; --t: 70%; margin-top: 1.2rem\" </div <div class=\"lbl\"",
   "quote": "Writing the target down before the engine existed meant the miss could not be reframed afterwards.",
   "evidence": [
    "Load testing and capacity engineering: a concurrency ladder from 1 to 2,048 clients with abort conditions at every rung; a burst of 2,048 served at 85.9 requests per second with none failed.",
    "Backpressure design: bounded endpoints that return busy with a retry hint or a fatal error with its own alarm counter, so search degrades to lexical results instead of failing.",
    "Performance benchmarking methodology: a pre-registered sustained target of 200 requests per second reported as missed at 6.9 because about 6 GB of key-value memory was needed against 1.4 free.",
    "Benchmark harness debugging: a slow observation write traced to a benchmark harness that forked a process per call, with a hypothesised cause retracted."
   ],
   "technology_kind": "discipline"
  },
  {
   "url": "https://coreyjames.ai/technologies/cargo/",
   "kind": "technology",
   "title": "Cargo",
   "subtitle": "Multi-crate workspaces, feature-gated builds and a carve gate that keeps product crates free of estate-specific imports.",
   "systems": [
    "agentos",
    "agent-swarm",
    "inference-fabric"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "546,000",
     "label": "lines of Rust in AgentOS"
    },
    {
     "value": "19",
     "label": "members in the AgentOS workspace"
    },
    {
     "value": "23",
     "label": "crates in Agent Swarm, split into a product zone and an estate zone"
    },
    {
     "value": "3",
     "label": "deploy modes besides the full run: dry-run, local-only, skip-build"
    }
   ],
   "lede": "One deploy verb for people and agents AgentOS is a Rust Cargo workspace that ships a manifest of binaries. I wanted one deploy path that nobody, human or agent, could get half right, in place of ad hoc copy steps across a multi-crate estate. Deployment is a single Cargo verb, cargo deploy , built with the xtask pattern as a workspace member and wired in through a Cargo alias. design <figure class=\"dv-figure\" aria-label=\"What cargo deploy does, in order\" <div style=\"display: flex; gap: 2px; min-height: 34px; border-radius: 8px; overflow: hidden; margin-top: 0.7rem\" <div style=\"flex: 3; background: color-mix(in srgb, var(--tone) 45%, var(--surface)); display: flex; align-items: center; padding: 3px 8px; color: var(--ink); font-size: clamp(0.6rem, 2.5vw, 0.74rem); font-weight: 600; line-height: 1.15\" release build</div <div",
   "quote": "Carve gates and dependency firewalls are checks that fail the build; a README cannot enforce architecture.",
   "evidence": [
    "Build and release engineering: one deploy verb for a 546,000-line Rust workspace of 19 members, publishing binaries by atomic symlink swap so nothing launches a half-written file.",
    "Architecture enforcement in the build: a carve gate across 23 crates that fails the check when a product crate imports estate-specific code, and a CI firewall keeping CUDA out of a storage daemon."
   ],
   "technology_kind": "platform"
  },
  {
   "url": "https://coreyjames.ai/technologies/catalog-versioning-and-drift-detection/",
   "kind": "technology",
   "title": "Catalog versioning and drift detection",
   "subtitle": "Every host in my agent fleet runs the same approved tool catalog, verified by content hash, with drift detection that falls back from notifications to polling under measured thresholds and never flaps.",
   "systems": [
    "agent-swarm",
    "capabilities-model"
   ],
   "technologies": [],
   "stats": [],
   "lede": "I treat agent configuration with the same consistency engineering as replicated data. One catalog version on every host Agent Swarm changes personas and tools while agents run on several hosts, and I saw two ways that goes wrong: hosts silently diverge, and an old agent binds to a retired tool. I started with a catalog version that means the same thing everywhere. design <figure class=\"dv-figure\" aria-label=\"What identifies a catalog version and where it lives\" <div style=\"display: flex; flex-wrap: wrap; gap: 0.9rem 1.2rem; align-items: center\" <div style=\"flex: 1 1 150px\" <div style=\"display: grid; grid-template-columns: repeat(6, 1fr); gap: 3px\" <span style=\"height: 12px; border-radius: 3px; background: var(--tone)\" </span <span style=\"height: 12px; border-radius: 3px; background: var(--tone); opacity: 0.45\" </span <span style=\"height: 12px; border-radius: 3px;",
   "quote": "Evaluation inputs are frozen by fingerprint, which ties every measurement to the exact catalog it ran against.",
   "evidence": [
    "Configuration drift detection: every host's tool catalog checked every 30 s against a SHA-256 content hash held in PostgreSQL and swapped atomically in process on a sustained mismatch.",
    "Event-driven change propagation: PostgreSQL LISTEN/NOTIFY with a fallback to polling past backlog and lag thresholds, and lower return thresholds with a hold so hosts never flap.",
    "ML evaluation methodology: an evaluation catalog frozen under a checksum after it drifted under a baseline, with the affected measurements re-run against the frozen version."
   ],
   "technology_kind": "discipline"
  },
  {
   "url": "https://coreyjames.ai/technologies/cbor/",
   "kind": "technology",
   "title": "CBOR",
   "subtitle": "Canonical CBOR encodes the vector store's RPC wire and the extraction specifications, so equal specifications are byte-identical.",
   "systems": [
    "inference-fabric",
    "capabilities-model"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "33",
     "label": "RPC variants in the vector store's service API"
    },
    {
     "value": "6",
     "label": "families they fall into, search among them"
    },
    {
     "value": "3",
     "label": "encodings across the fabric's links"
    }
   ],
   "lede": "One wire for requests and vectors Inference Fabric's Vector Shard Manager needed a wire that carries small structured requests and large binary vector payloads in the same frame. I chose CBOR, length-prefixed over TCP to mirror the framing of the fabric's broker protocol, through the ciborium Rust library. design <figure class=\"dv-figure\" aria-label=\"The vector store's RPC surface\" <span class=\"eyebrow\" style=\"margin-top: 0\" One frame per call · request fields and binary payload · illustrative</span <div style=\"display: grid; grid-template-columns: 10rem minmax(0, 1fr) 0; gap: 0.7rem; align-items: center; font-size: 0.82rem; margin-top: 0.5rem\" <span Payload appends</span <div class=\"lane\" style=\"height: 16px; border-radius: 8px\" <i style=\"left: 0%; width: 10%; background: color-mix(in srgb, var(--tone) 45%, var(--surface))\" </i <i style=\"left: 11%; width: 78%; background: var(--tone)\" </i </div <span </span",
   "quote": "I use canonical encoding wherever bytes stand for identity.",
   "evidence": [
    "Binary wire protocol design: a length-prefixed CBOR wire for a vector store with 33 RPC variants in 6 families, carrying structured fields and binary vectors in one frame with no base64 step.",
    "Canonical encoding and content identity: hidden-state extraction specs encoded as canonical CBOR so equal specs are byte-identical and their identifiers match wherever they were produced."
   ],
   "technology_kind": "protocol"
  },
  {
   "url": "https://coreyjames.ai/technologies/chrome-extensions-manifest-v3/",
   "kind": "technology",
   "title": "Chrome extensions (Manifest V3)",
   "subtitle": "A browser extension lets an agent act through my own authenticated browser session where no API exists, with duplicate-safe receipts and a read-back after every change.",
   "systems": [
    "fafohive"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "~800",
     "label": "lines across the extension, native host and installer"
    },
    {
     "value": "6",
     "label": "agent tools behind it"
    },
    {
     "value": "5",
     "label": "read-only checks at most after each change, one second apart"
    }
   ],
   "lede": "Working through the browser I already use FAFOHive needed a way for agents to read Reddit threads and to post, edit and delete their own comments, and no Reddit API path was usable from my estate. Copying session cookies to a server or running an automation browser would have moved my credentials somewhere they should never be. So I built a Manifest V3 Chrome extension that lives in my normal, signed-in Chrome. The provider service reaches it through Chrome's native messaging, the extension returns only results, and the provider is reachable only through the existing tunnel. design <figure class=\"dv-figure\" aria-label=\"The earlier bridge and the one kept\" <div class=\"dv-two\" <div <span class=\"eyebrow\" style=\"margin-top: 0\" Dropped · headless bridge</span <div style=\"display: flex;",
   "quote": "A change counts when the page itself shows it.",
   "evidence": [
    "Browser extension development (Manifest V3): about 800 lines across an extension, native host and installer that let agents act through a signed-in browser session where no API exists, with no copied cookies.",
    "Idempotent agent actions on external platforms: every change read back with at most 5 read-only checks one second apart, idempotency keys bound to inputs, and an unconfirmed send never resent."
   ],
   "technology_kind": "platform"
  },
  {
   "url": "https://coreyjames.ai/technologies/cloudflare-tunnel/",
   "kind": "technology",
   "title": "Cloudflare Tunnel",
   "subtitle": "Tunnelled ingress means my estate has no open inbound ports.",
   "systems": [
    "auth-and-access-plane",
    "helix",
    "fafohive"
   ],
   "technologies": [],
   "stats": [],
   "lede": "Every public surface, from the memory gateway to the Teams bridge, arrives through an authenticated tunnel. Outbound tunnels, one per purpose Auth and access plane lets outside services reach parts of my estate. I chose outbound-only Cloudflare tunnels and split them by purpose, so webhook intake and the social bridges can be shut without touching the main estate. design <figure class=\"dv-figure\" aria-label=\"A cross-section of one public surface\" <div style=\"width: 100%; margin: 6px auto 0; border-radius: 8px; background: var(--rule); color: var(--ink); padding: 9px 12px; display: flex; justify-content: space-between; gap: 10px; flex-wrap: wrap; font-size: 0.8rem\" <strong style=\"color: inherit\" Edge Worker</strong <span style=\"opacity: .85\" only where a vendor needs a public surface</span </div <div style=\"width: 84%; margin: 6px auto 0; border-radius: 8px; background:",
   "quote": "I check access control by trying to get in.",
   "evidence": [
    "Zero-trust and zero-inbound networking: every public surface carried by outbound-only tunnels split by purpose, with no inbound port open and services bound to loopback behind NGINX.",
    "Access control testing: a re-pointed route behind Cloudflare Access proved from both sides, an authorised check returning 200 while an anonymous request got 403 and a direct connection was dropped at the firewall."
   ],
   "technology_kind": "platform"
  },
  {
   "url": "https://coreyjames.ai/technologies/cloudflare-workers/",
   "kind": "technology",
   "title": "Cloudflare Workers",
   "subtitle": "An edge worker exposes a trimmed, authenticated tool surface to a vendor's agent platform without opening the estate behind it.",
   "systems": [
    "auth-and-access-plane",
    "fafohive"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "~300",
     "label": "lines of JavaScript in the Copilot Studio Worker"
    },
    {
     "value": "2",
     "label": "key slots, so credentials rotate without an outage"
    },
    {
     "value": "300 s",
     "label": "replay window on signed events"
    },
    {
     "value": "5 min",
     "label": "between edge sweeps for events past their service window"
    }
   ],
   "lede": "A trimmed surface for Copilot Studio Auth and access plane lets Microsoft Copilot Studio call tools in my private estate, and its connector behaves in ways its documentation does not describe. I put a Cloudflare Worker in front of the estate as the connector's only public surface. The edge runtime has none of the usual crypto libraries, so tokens are verified with WebCrypto against signing keys cached in KV. design <figure class=\"dv-figure\" aria-label=\"Rotating the access key without an outage\" <span class=\"eyebrow\" style=\"margin-top: 0\" Two key slots across a rotation · illustrative</span <div style=\"display: grid; grid-template-columns: minmax(4.5rem, 9.5rem) minmax(4rem, 1fr) minmax(2.4rem, 5.5rem); gap: 0.7rem; align-items: center; font-size: 0.82rem; margin-top: 0.5rem\" <span Slot A, old key</span <div class=\"lane\" style=\"height: 14px; border-radius: 7px\"",
   "quote": "I shape integrations from how a vendor's client behaves in practice.",
   "evidence": [
    "Edge authentication: a ~300-line Cloudflare Worker as the only public surface for Copilot Studio, verifying tokens with WebCrypto against keys cached in KV, with 2 key slots for rotation without an outage.",
    "Webhook ingestion and verification: signed events checked at the edge with an exact-body HMAC and a 300 s replay window, deduplicated by event ID, and swept every 5 min for anything past its service window."
   ],
   "technology_kind": "platform"
  },
  {
   "url": "https://coreyjames.ai/technologies/cluster-health-metrics-on-the-gpu/",
   "kind": "technology",
   "title": "Cluster-health metrics on the GPU",
   "subtitle": "Per-cluster metrics, each answering a question a corpus manager asks, computed across thousands of clusters in fused GPU launches and defined by CPU reference code.",
   "systems": [
    "inference-fabric"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "6",
     "label": "families of metrics, each answering one kind of question about a cluster"
    },
    {
     "value": "~12",
     "label": "fused GPU launches for a batch of thousands of clusters"
    },
    {
     "value": "8",
     "label": "operational metrics about a cluster's life in the database, beside the geometry"
    },
    {
     "value": "5",
     "label": "composite scores, weighted from a table in the database"
    }
   ],
   "lede": "What the engine measures My distillation research keeps millions of embeddings in clusters, and the corpus is managed by what the clusters measure: a cluster is split, merged or left alone on the strength of its scores. I built a CUDA engine that computes every metric across every cluster at once, under the Inference Fabric on the same leased GPU memory as the search kernels. design <figure class=\"dv-figure\" aria-label=\"One cluster around its centroid, and the six questions asked of it\" <div style=\"display:flex;gap:18px;align-items:center;flex-wrap:wrap\" <div class=\"dv-ring\" aria-hidden=\"true\" style=\"flex:none\" <i style=\"--i: 0\" </i <i style=\"--i: 1\" class=on </i <i style=\"--i: 2\" class=on </i <i style=\"--i: 3\" </i <i style=\"--i: 4\" class=on </i <i style=\"--i: 5\" class=on </i <i style=\"--i: 6\" </i <i style=\"--i:",
   "quote": "A number means the same thing wherever it is read.",
   "evidence": [
    "Embedding analytics and cluster metrics: thirty-eight per-cluster metrics in 6 families, each answering a question a corpus manager asks, folded into 5 composite scores.",
    "CUDA kernel development: clusters of any size computed together through compressed-row offsets, a batch of thousands of clusters in ~12 fused GPU launches.",
    "Numerical validation against CPU references: every metric defined by CPU reference code, with each kernel checked against it at a single-precision tolerance."
   ],
   "technology_kind": "discipline"
  },
  {
   "url": "https://coreyjames.ai/technologies/code-generation-and-metaprogramming/",
   "kind": "technology",
   "title": "Code generation and metaprogramming",
   "subtitle": "I generate code where repetition is the risk: a generator that emits a whole function and wires it into the estate transactionally, and YAML tool schemas compiled into dispatch at build time.",
   "systems": [
    "fafo-core",
    "fafohive"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "8 + 6",
     "label": "files in each generated crate: framework the author leaves alone, and a sandboxed developer zone"
    },
    {
     "value": "7 of 14",
     "label": "function crates in the estate carry the generator's fingerprints"
    },
    {
     "value": "83",
     "label": "operations compiled from a vendor's OpenAPI specification into an internal catalog"
    },
    {
     "value": "15",
     "label": "points in the integration check the first generator passed while its code did not compile"
    }
   ],
   "lede": "A generator that wires a function into the estate In FAFO Core and Function Forge, every new capability used to mean a person wiring a crate into the gateway, the control plane and the result path by hand, and a half-wired function shows up later as a hang. I decided agents should generate fully wired functions themselves, inside a sandbox, active only after a human rebuild. Function Forge is a Rust generator built on Handlebars templates and exposed as an MCP (Model Context Protocol) tool. One create function call emits the crate and, in the same rollback-protected transaction, edits the rest of the estate: the gateway's module, function and metadata definitions, the control plane's composition root and the completion service's",
   "quote": "The generated breadth stays private.",
   "evidence": [
    "Code generation and metaprogramming: a Rust generator on Handlebars templates that emits a crate of 8 + 6 files and edits four services in one rollback-protected transaction.",
    "Tool synthesis and governed API integration: a vendor OpenAPI specification compiled into an internal catalog of 83 typed, costed operations, with about fifteen designed tools shown to agents.",
    "Sandboxing for AI-authored code: generated logic confined to a developer zone with a capability-bounded context object, active only after a rebuild and a human restart.",
    "Build-time schema compilation: YAML tool definitions compiled into dispatch code and JSON-Schema tool inputs at build time."
   ],
   "technology_kind": "discipline"
  },
  {
   "url": "https://coreyjames.ai/technologies/code-graph-and-static-dependency-analysis/",
   "kind": "technology",
   "title": "Code graph and static dependency analysis",
   "subtitle": "The code graph under my memory service is extracted with a parser into partitioned edge tables; dependency traces are bounded database traversals with no model involved, and the explainer may narrate only proven edges.",
   "systems": [
    "fafohive"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "6",
     "label": "edge kinds extracted from source by the parser"
    },
    {
     "value": "3",
     "label": "languages with edge extractors: Rust, Python and TypeScript"
    },
    {
     "value": "294,033",
     "label": "of the index's 294,362 code chunks covered by the graph"
    },
    {
     "value": "~19,000",
     "label": "files in the monorepo the graph is built over"
    }
   ],
   "lede": "Edges from a parser, not from a model In FAFOHive, my agents had to know the blast radius of a symbol before changing it, and a language model asked for call paths invents some. design <blockquote class=\"dv-quote\" <p Structure must come from a parser and a database; a model may only put that structure into words.</p </blockquote tree-sitter extracts calls, imports, implements, references, definitions and re-exports from source, and they land in partitioned PostgreSQL edge tables. An edge whose endpoint is not indexed yet stays pending, and a resolver promotes it only once both endpoints are indexed. Graph generations let me rebuild an index without serving a half-built graph, and each request is pinned to one generation. design <figure class=\"dv-figure\"",
   "quote": "Structure must come from a parser and a database; a model may only put that structure into words.",
   "evidence": [
    "Static dependency analysis: a parser-built code graph of 6 edge kinds over a monorepo of ~19,000 files, covering 294,033 of 294,362 code chunks.",
    "PostgreSQL graph traversal: dependency traces as bounded breadth-first searches in SQL with a Redis fast path and no model call.",
    "Evidence-grounded LLM output: an explainer that hands a model only a path the code graph has proven, up to five hops."
   ],
   "technology_kind": "discipline"
  },
  {
   "url": "https://coreyjames.ai/technologies/comfyui/",
   "kind": "technology",
   "title": "ComfyUI",
   "subtitle": "A node-based media pipeline runs as a GPU media studio behind my memory gateway, with provenance tracked on every generated asset.",
   "systems": [
    "fafohive"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "33",
     "label": "media tools any agent can call"
    },
    {
     "value": "1",
     "label": "CPU-only controller container per host"
    },
    {
     "value": "9",
     "label": "frames in the video workflows that render and deliver end to end"
    }
   ],
   "lede": "A controller in front of an unmodified engine FAFOHive hosts a GPU media studio as tools any agent can call, and ComfyUI is its render engine. The risk I saw was agents treating a GPU and a third-party HTTP engine as free and repeatable: a retried render costs GPU time, a crash mid-render leaves an unknown outcome, and an agent-supplied Docker or shell option is an escape hatch. I decided to leave ComfyUI unmodified and put all of the control in a Rust controller in front of it. ComfyUI's own APIs do the rendering; I built no engine and changed none of its code. design <figure class=\"dv-figure\" aria-label=\"What the controller does around the engine\" <div style=\"width: 100%; margin: 6px auto",
   "quote": "When agents are the callers, I wrap third-party engines in idempotent, crash-safe control and place the human decision at the licence boundary.",
   "evidence": [
    "Governed AI media pipelines: 33 media tools for agents on an unmodified ComfyUI engine behind a Rust controller that accepts typed choices only, with no Docker options, mounts or shell strings.",
    "Exactly-once delivery and crash recovery: render identity persisted before submission, uncertain outcomes reconciled against the engine and never resubmitted, outputs registered immutably.",
    "Human approval at the licence boundary: model downloads approved by a person at a local console that no remote call can reach, then resumable, hash-checked and registered."
   ],
   "technology_kind": "platform"
  },
  {
   "url": "https://coreyjames.ai/technologies/context-engineering-and-persistent-agent-memory/",
   "kind": "technology",
   "title": "Context engineering and persistent agent memory",
   "subtitle": "Agents forget between sessions, so I built the memory that remembers for them: every tool call captured, extracted and re-injected into later sessions, and a council shell with durable state in PostgreSQL.",
   "systems": [
    "fafohive",
    "helix"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "7",
     "label": "lifecycle events hooked, from session start to sub-agent stop"
    },
    {
     "value": "~6,000",
     "label": "tokens of grounding per turn, the budget for one scope"
    }
   ],
   "lede": "Memory that outlives the session In FAFOHive, my coding agents used to forget everything between sessions and rediscover the same facts about my code over and over. Hooks on the coding agent's lifecycle events capture every tool interaction, and a worker pool hands each one to a configurable model provider, local models included. design <figure class=\"dv-figure\" aria-label=\"One tool interaction becoming context for a later session\" <div style=\"display:flex;gap:16px;align-items:center;flex-wrap:wrap\" <div style=\"flex:1 1 380px\" <div style=\"margin-top: 0.3rem\" <div style=\"display: grid; grid-template-columns: 20px minmax(0, 1fr); gap: 0.8rem; align-items: start\" <div style=\"display: flex; flex-direction: column; align-items: center; align-self: stretch\" <span style=\"width: 20px; height: 20px; border-radius: 50%; background: var(--tone); flex: none\" </span <span style=\"flex: 1; width: 3px; min-height: 14px; background: var(--tone)\" </span </div <span style=\"font-size: 0.86rem;",
   "quote": "Knowledge outlives any model session, so the system owns the context and each model holds only its own continuity.",
   "evidence": [
    "Persistent memory for AI agents: 7 lifecycle events hooked to capture every tool interaction, which is extracted, embedded, stored in PostgreSQL and injected into later sessions.",
    "Context engineering for multi-model systems: one authoritative context owned by the system, with each model given a scoped grounding packet budgeted at ~6,000 tokens per turn.",
    "Scoped retrieval for agent hierarchies: context follows a system, project, work order and conversation hierarchy, and a work order never sees a sibling."
   ],
   "technology_kind": "discipline"
  },
  {
   "url": "https://coreyjames.ai/technologies/contract-first-interface-design/",
   "kind": "technology",
   "title": "Contract-first interface design",
   "subtitle": "Every job an agent receives in my governance platform carries a schema that says what must come back. Contracts first, prose only for behaviour.",
   "systems": [
    "agentos"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "10",
     "label": "seams in the registry, each with producer, consumer, schema and refusal tests"
    },
    {
     "value": "6 + 4",
     "label": "input contracts and overlays delivered in the first phase"
    },
    {
     "value": "4.78 MB",
     "label": "the packet that went out past a ceiling one launch path never checked"
    }
   ],
   "lede": "A contract for every task In AgentOS, free-form messages between agents were where long runs drifted, so I made every handoff in AgentOS a typed contract from its first phase. That phase delivered the input contracts and overlays under change control, pinned by a hashed manifest. Each task gets an execution contract rendered by AgentOS. design <figure class=\"dv-figure\" aria-label=\"What one task's execution contract carries\" <div class=\"dv-two\" <div <span class=\"eyebrow\" One task's execution contract</span <div style=\"margin-top:0.6rem;border:1.5px solid var(--rule);border-radius:10px;overflow:hidden\" <div style=\"height:34px;background:var(--bg);display:flex;align-items:center;padding:0 10px;border-top:1px solid var(--rule)\" <span class=\"lbl\" style=\"color:var(--ink-3)\" Write roots: where the agent may write</span </div <div style=\"height:34px;background:var(--bg);display:flex;align-items:center;padding:0 10px;border-top:1px solid var(--rule)\" <span class=\"lbl\" style=\"color:var(--ink-3)\" Sealed dependencies</span </div <div style=\"height:48px;background:var(--tone-soft);display:flex;align-items:center;padding:0 10px;border-top:1px solid var(--rule)\" <span class=\"lbl\" style=\"color:var(--ink)\" Grounding the job needs</span </div <div style=\"height:64px;background:var(--tone);display:flex;align-items:center;padding:0 10px;border-top:1px",
   "quote": "A declared limit nobody checks is documentation.",
   "evidence": [
    "Contract-first interface design: every agent handoff a typed contract validated by producer and consumer against one JSON Schema, in a registry of 10 seams with refusal tests.",
    "Multi-agent governance: execution contracts that name write roots, sealed dependencies and the evidence a task must return, under envelopes of ratified autonomy.",
    "Limit enforcement at choke points: a packet-size ceiling moved into both choke points after a 4.78 MB packet passed a launch path that never checked it."
   ],
   "technology_kind": "discipline"
  },
  {
   "url": "https://coreyjames.ai/technologies/conversational-turn-taking-and-barge-in/",
   "kind": "technology",
   "title": "Conversational turn-taking and barge-in",
   "subtitle": "I built a voice engine in which several AI voices share one conversation without talking over each other, and a person speaking stops the agent.",
   "systems": [
    "helix"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "0",
     "label": "stale audio after an interruption in the local voice room"
    }
   ],
   "lede": "A person speaking stops every agent In Helix, a voice colleague that keeps talking when someone starts to speak is unusable, so I made interruption the first requirement of Helix's voice engine. When a person starts speaking while an agent talks, the agent stops. If several agents are speaking or about to speak, all of them stop, and nothing from before the interruption plays afterwards. design <blockquote class=\"dv-quote\" <p I judge an interruption by what plays afterwards.</p </blockquote The conversation history keeps what the room heard, so a reply cut off halfway is stored cut off and later reasoning builds on the words people actually heard. design <figure class=\"dv-figure\" aria-label=\"A reply as the model wrote it, and as the history",
   "quote": "I judge an interruption by what plays afterwards.",
   "evidence": [
    "Real-time voice AI: barge-in where a person speaking stops every agent, with 0 stale audio after an interruption in the local voice room.",
    "Conversational AI design: several AI voices in one conversation, a persona addressed by its name at the start of a sentence, and background results spoken at the next pause.",
    "Microsoft Teams voice integration: one conversation engine behind a desk microphone and a Teams call, so behaviour proven in the room carries into calls."
   ],
   "technology_kind": "discipline"
  },
  {
   "url": "https://coreyjames.ai/technologies/cost-attribution-for-ai-work/",
   "kind": "technology",
   "title": "Cost attribution for AI work",
   "subtitle": "Every token my agents spend is attributed to the work order that bought it.",
   "systems": [
    "agentos"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "31,811",
     "label": "metered usage records tied to work orders"
    },
    {
     "value": "246",
     "label": "work orders those records roll up to"
    },
    {
     "value": "43–97%",
     "label": "cache reuse across seats on one work order over a 24-hour window"
    }
   ],
   "lede": "Every token placed against the work that bought it AI work costs money per token, and a cost nobody can tie to a deliverable cannot be managed. AgentOS gathers usage from three sources. Hooks capture coding-agent transcripts. Managed seats emit signed, replay-safe usage events, each attributed to the model the provider reported, which is the model that actually ran. Planning a work order costs tokens too. A capture step binds the authoring of a work order to the exact native conversation where the planning happened, passing only private file references, so no transcript content crosses the tool boundary. design <figure class=\"dv-figure\" aria-label=\"One cost row cut into its fields, and metered usage against attributed usage with the unplaced remainder shown as",
   "quote": "Cost informs strategy and must never silently block dispatch.",
   "evidence": [
    "Cost attribution for AI work: 31,811 metered usage records tied to 246 work orders, every token placed on the work that bought it.",
    "Engineering productivity metrics: a value measure rebuilt after 99.7 percent of the first version's headline turned out to be token spend.",
    "Prompt caching analysis: cache reuse of 43-97% across seats on one work order over a 24-hour window."
   ],
   "technology_kind": "discipline"
  },
  {
   "url": "https://coreyjames.ai/technologies/cpu-reference-implementations-and-gpu-equivalence-testing/",
   "kind": "technology",
   "title": "CPU reference implementations and GPU equivalence testing",
   "subtitle": "Every GPU metric has a plain-Rust CPU twin that defines it.",
   "systems": [
    "inference-fabric"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "~9,000",
     "label": "lines of plain-Rust reference across thirteen modules"
    },
    {
     "value": "32",
     "label": "Rust integration tests, beside fifteen CUDA test files"
    },
    {
     "value": "20",
     "label": "older kernels kept with tests as regression baselines"
    }
   ],
   "lede": "The reference is the definition In the Inference Fabric's CUDA engine every metric and every search family has a CPU reference in plain Rust. The reference states the formula the obvious way and decides every edge case; the kernel is an implementation that must match it. design <blockquote class=\"dv-quote\" <p I do not trust a GPU kernel to define the number it computes.</p </blockquote A consistency check keeps the kernels, the references and the per-kernel lineage documentation in agreement for every kernel group. A metric that has no kernel yet stays on the CPU with its limit stated. The method is told in Every metric gets a CPU twin. design <figure class=\"dv-figure\" aria-label=\"A metric whose GPU kernel is held equal",
   "quote": "I do not trust a GPU kernel to define the number it computes.",
   "evidence": [
    "Numerical testing of GPU kernels: a plain-Rust CPU reference of about 9,000 lines behind every metric, with a three-way check between kernel, reference and documentation.",
    "Floating-point tolerance design: tolerances derived from single-precision reductions on 1,024-dimensional vectors, exact and byte-identical where search promises determinism.",
    "Regression testing for GPU code: 32 Rust integration tests and 20 older kernels kept as baselines a rewrite is measured against."
   ],
   "technology_kind": "discipline"
  },
  {
   "url": "https://coreyjames.ai/technologies/credential-brokering-and-secrets-management/",
   "kind": "technology",
   "title": "Credential brokering and secrets management",
   "subtitle": "No agent in my estate holds a credential it does not need, and most hold none.",
   "systems": [
    "agentos",
    "agent-swarm"
   ],
   "technologies": [],
   "stats": [],
   "lede": "A gatekeeper holds each domain credential The usual way to give an agent access is a scoped token and hope. In Agent Swarm I wanted a plain property instead: an agent cannot call what it was not granted and never holds a credential it does not need. How sensitive an action is depends on which agent holds the credential for it, so I decide which agent may hold one, and every other agent asks that one for an outcome. design <blockquote class=\"dv-quote\" <p Sensitivity follows the holder.</p </blockquote Git is the domain with its own gatekeeper. A coding agent on a local open-source model edits, tests and pushes to its own branch in a throwaway container, then asks the gatekeeper",
   "quote": "Sensitivity follows the holder.",
   "evidence": [
    "Identity and least privilege for AI agents: a gatekeeper persona holds the git credential, and a coding agent on a local model opens merge requests without ever holding it.",
    "Secrets management: operator tools that store, rotate, revoke, list and push secrets without ever returning a value, and no secret bytes in any log.",
    "Credential isolation for managed AI seats: each seat's login held by reference in its own private state directory, never in an image or a log."
   ],
   "technology_kind": "discipline"
  },
  {
   "url": "https://coreyjames.ai/technologies/cuda-c-plus-plus/",
   "kind": "technology",
   "title": "CUDA C++",
   "subtitle": "I write CUDA where it earns its place: a cluster-health and vector-search engine for the newest NVIDIA architecture, and a tool-discovery decoder whose reductions are ordered so output bits never depend on the batch.",
   "systems": [
    "inference-fabric",
    "activekv",
    "capabilities-model"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "29",
     "label": "kernels in 13 families, with exact, inverted-file and lattice search"
    },
    {
     "value": "59",
     "label": "kernel and header files in the analytics engine, tests included"
    },
    {
     "value": "~500,000",
     "label": "vectors a second for two-means clustering, rewritten without atomics"
    },
    {
     "value": "2,740",
     "label": "MiB, the batched decoder's footprint beside the serving model"
    }
   ],
   "lede": "Cluster-health kernels with no library to lean on In the Inference Fabric I needed health statistics for every embedding cluster computed on the GPU next to vector search, over millions of vectors on consumer cards, and no library offered them, so I had the kernels written. Every kernel takes all clusters in one launch. Linear-time statistics run one block per cluster with a grid-stride loop and block reductions. Pairwise statistics run one block per pair of tiles; the dimension loop sits outside the pair loop so every thread reaches every barrier. design <figure class=\"dv-figure\" aria-label=\"Pairwise statistics in tiles\" <div class=\"dv-two\" <div <span class=\"eyebrow\" Tile pairs of one cluster</span <div style=\"display: grid; grid-template-columns: repeat(6, 1fr); gap: 4px; max-width: 220px; margin-top: 0.8rem\"",
   "quote": "Every kernel has a CPU reference and an equivalence test, so a fast kernel is never the only definition of the answer.",
   "evidence": [
    "CUDA kernel development: a cluster-health and vector-search engine of 29 kernels in 13 families, with exact, inverted-file and lattice search, each kernel with a CPU reference and an equivalence test.",
    "CUDA performance optimisation: a centroid kernel rebuilt in three passes without atomics, from 521 ms to 47 ms at 100,000 vectors per cluster, and two-means clustering rewritten to about 500,000 vectors a second.",
    "Deterministic GPU computation: a CUDA decoder with one block per output row, a fixed reduction order and no K-split tiling, so output bits never depend on the batch, in 2,740 MiB beside the serving model.",
    "NVIDIA Blackwell development: decode as a device graph with a device-side conditional, about 518 microseconds removed from every token, and NVFP4 weights 2.53 times smaller than FP8 at about 5 percent slower at batch 1."
   ],
   "technology_kind": "language"
  },
  {
   "url": "https://coreyjames.ai/technologies/cuda-driver-api/",
   "kind": "technology",
   "title": "CUDA Driver API",
   "subtitle": "My CUDA analytics engine talks to the driver API directly from Rust, built for a GPU architecture the Rust ecosystem had not caught up with.",
   "systems": [
    "inference-fabric"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "2",
     "label": "Blackwell GPUs the engine loads its own cubins onto"
    },
    {
     "value": "3",
     "label": "memory classes a lease can hold"
    },
    {
     "value": "13.1",
     "label": "the CUDA version the build defaults to"
    }
   ],
   "lede": "Raw FFI for an architecture nobody had wrapped In the Inference Fabric I was targeting CUDA 13 and NVIDIA Blackwell when no Rust CUDA crate supported either, and I needed to ship compiled kernels to remote workers and control streams, events and devices directly. I chose raw CUDA Driver API FFI from Rust, because no wrapper supported the toolkit and the architecture, and because cubin loading had to stay under my control. The Driver API is the same across the Blackwell generation. design <figure class=\"dv-figure\" aria-label=\"Moving to a datacentre Blackwell part\" <div style=\"width: 46%; margin: 6px auto 0; border-radius: 8px; background: var(--orange); color: var(--ink); padding: 9px 12px; display: flex; justify-content: space-between; gap: 10px; flex-wrap: wrap; font-size: 0.8rem\" <strong style=\"color: inherit\"",
   "quote": "I work at the level of contexts, modules, streams and host memory registration when the higher-level tools do not yet reach the hardware I am using.",
   "evidence": [
    "CUDA Driver API from Rust: raw FFI over CUDA 13 for 2 Blackwell GPUs before any Rust crate supported them, loading native cubins with no PTX embedded and refusing any other device.",
    "GPU memory management: a lease layer with 3 memory classes that pins host memory with cuMemHostRegister, staging page-cache data into an anonymous buffer the kernel will pin.",
    "Async runtime and GPU integration: one primary CUDA context retained per process for Tokio's moving blocking-pool threads, and a GPU-side doorbell on cuStreamWaitValue64 with no host polling."
   ],
   "technology_kind": "runtime"
  },
  {
   "url": "https://coreyjames.ai/technologies/cutlass/",
   "kind": "technology",
   "title": "CUTLASS",
   "subtitle": "CUTLASS-for-SYCL is part of the kernel stack I patched on Intel's Xe2 architecture for ActiveKV's attention.",
   "systems": [
    "activekv"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "3",
     "label": "kernel libraries in the release built on it"
    },
    {
     "value": "2",
     "label": "attention needs the stock kernels did not meet"
    },
    {
     "value": "2",
     "label": "candidate changes rejected and kept as negative results"
    }
   ],
   "lede": "Extending the vendor's templates ActiveKV needed two things from attention on the Intel Arc Pro GPU that stock kernels do not provide, and I decided to extend Intel's CUTLASS and CuTe port for SYCL to get them. The library comes from the CUTLASS 4.2.1 lineage. The vendor's templates already encode the tile, copy and MMA structure for Xe2, so I added only what ActiveKV needed. design <figure class=\"dv-figure\" aria-label=\"Where CUTLASS-for-SYCL sits in the release\" <div style=\"display: grid; grid-template-columns: repeat(3, 1fr); gap: 6px\" <div style=\"width: 100%; margin: 6px auto 0; border-radius: 8px; background: var(--tone); color: var(--on-navy); padding: 9px 12px; display: flex; justify-content: space-between; gap: 10px; flex-wrap: wrap; font-size: 0.8rem\" <strong style=\"color: inherit\" Paged attention</strong <span style=\"opacity: .85\" </span </div <div style=\"width:",
   "quote": "No kernel patch ships unless its outputs match the unpatched path bit for bit.",
   "evidence": [
    "Intel GPU and SYCL/oneAPI engineering: Intel's CUTLASS-for-SYCL templates extended on Xe2 for 2 attention needs, compiled into 3 kernel libraries inside the vendor's own toolchain for ABI match.",
    "Bit-exact numerical verification: log-sum-exp added to paged decode so attention over card and host memory merges exactly, every patch gated on output bit-identical to the unpatched path, with 2 candidates rejected."
   ],
   "technology_kind": "framework"
  },
  {
   "url": "https://coreyjames.ai/technologies/database-performance-diagnosis/",
   "kind": "technology",
   "title": "Database performance diagnosis",
   "subtitle": "I diagnose database performance from the database's own statistics, one change at a time.",
   "systems": [
    "postgresql-fabric",
    "fafo-core"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "196 → 0",
     "label": "deadlocks in the same workload, after one index"
    },
    {
     "value": "6,752",
     "label": "rows per second on average, peaking at 16,370"
    },
    {
     "value": "185 s",
     "label": "to write 1,249,048 rows"
    }
   ],
   "lede": "Choosing the instrument before measuring FAFO Core and Function Forge sends every database write in the estate through one governed write path, so when a bulk update slowed it, every producer slowed with it. Batches took up to two seconds, deadlocks came every few seconds, and the queue in front of the database reported healthy throughput. The queue counts rows taken in; only the database's tuple deltas count rows written. design <blockquote class=\"dv-quote\" <p The queue was the wrong instrument.</p </blockquote I had a benchmark harness built that samples the system through a controlled run and renders a before-and-after report. design <figure class=\"dv-figure\" aria-label=\"Three series sampled on a fixed interval through a controlled run, split at the one change: system",
   "quote": "The queue was the wrong instrument.",
   "evidence": [
    "PostgreSQL performance tuning: one unique index on the update key took a write path from 196 deadlocks to 0.",
    "Performance benchmarking methodology: tuple deltas as ground truth and one change between runs, 1,249,048 rows in 185 seconds at 6,752 rows per second on average.",
    "Database performance diagnosis: batch latency on the same workload cut from 100-2,000 ms to 7-37 ms."
   ],
   "technology_kind": "discipline"
  },
  {
   "url": "https://coreyjames.ai/technologies/declarative-tool-and-agent-definition/",
   "kind": "technology",
   "title": "Declarative tool and agent definition",
   "subtitle": "In my agent runtime a tool is a YAML declaration and an agent class is a composition.",
   "systems": [
    "agent-swarm",
    "agentos"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "40",
     "label": "declarative tools in the catalog, beside about twenty Rust built-ins"
    },
    {
     "value": "50",
     "label": "golden fixtures run through the runtime's own pipeline"
    },
    {
     "value": "29",
     "label": "personas declared, not coded"
    }
   ],
   "lede": "Tools declared as data Every new agent tends to arrive with its own tooling and permissions, and every one of those is a new place for something to go wrong, so in Agent Swarm I decided tools and agent roles would be data. Tools are declared in YAML in four kinds. Composed tools template from inputs and earlier results, with recursion detection and depth caps; HTTP templates use RFC 3986 encoding; and a peer service turns any agent into a tool provider. design <figure class=\"dv-figure\" aria-label=\"A declared tool drawn as a specification plate with six metadata settings\" <div style=\"overflow-x: auto\" <svg viewBox=\"0 0 520 172\" width=\"100%\" role=\"img\" aria-label=\"Tool metadata\" style=\"display: block; overflow: visible; min-width: 520px\" <rect x=\"0\" y=\"0\" width=\"520\" height=\"170\"",
   "quote": "Exceptions are where the holes are.",
   "evidence": [
    "Agent tool design: 40 declarative tools in YAML across four kinds, validated in strict mode and pushed through 50 golden fixtures.",
    "Agent orchestration: 29 personas declared, not coded, with model, provider and container kept in separate execution profiles.",
    "Security testing for agent tools: injection fixtures that attack every shell template, and a tool without tests fails the build."
   ],
   "technology_kind": "discipline"
  },
  {
   "url": "https://coreyjames.ai/technologies/determinism-and-numerical-reproducibility/",
   "kind": "technology",
   "title": "Determinism and numerical reproducibility",
   "subtitle": "Bit-identical or nothing, wherever the reference is bitwise with itself.",
   "systems": [
    "activekv",
    "capabilities-model",
    "inference-fabric"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "13 of 13",
     "label": "exact cells matched bitwise by the Python-to-C++ port, and 12 of 12 compressed"
    },
    {
     "value": "2,345",
     "label": "of 2,345 rank-one checks held across shuffled batch compositions"
    },
    {
     "value": "484",
     "label": "of 484 ranked lists matched against an independent implementation"
    }
   ],
   "lede": "Bit-for-bit parity for a native port A rewrite or a kernel patch that changes one output bit invalidates every parity result above it, so I made bit-for-bit reproducibility ActiveKV's release standard. The exact BF16 path passes only when its output is bit-identical to fully resident attention. To make that reachable, I had the paged-attention kernel patched to emit its log-sum-exp statistic, so attention computed over on-card and host-resident history merges exactly. For parity runs, a validation switch makes the variable 4-bit GEMM reductions deterministic, and the release build is bit-identical to it with the switch off. I wrote the parity doctrine, and its first rule is that I run the reference twice before trusting a bitwise gate. design <blockquote class=\"dv-quote\"",
   "quote": "A non-deterministic baseline fails against itself.",
   "evidence": [
    "Numerical reproducibility and bitwise validation: a Python-to-C++ port that matched 13 of 13 exact cells and 12 of 12 compressed cells bitwise.",
    "Deterministic GPU computation: a batched CUDA decoder identical across shuffled batch compositions in 2,345 of 2,345 rank-one checks, 484 of 484 ranked lists matched.",
    "Reproducible ML pipelines: NVFP4 quantisation in about 15 seconds, byte-identical on re-run, so a rebuilt model can be compared with the one it replaces."
   ],
   "technology_kind": "discipline"
  },
  {
   "url": "https://coreyjames.ai/technologies/distributed-job-orchestration/",
   "kind": "technology",
   "title": "Distributed job orchestration",
   "subtitle": "One function definition runs as a job or a service, batched by rows or by GPU token budget, anywhere from in-process to rented cloud GPUs, by configuration.",
   "systems": [
    "fafo-core"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "13",
     "label": "function crates built on the framework, beside eight service crates"
    },
    {
     "value": "19",
     "label": "control actions reaching running conductors, among them pause, scale, drain and inspect"
    },
    {
     "value": "970K",
     "label": "probes in flight at the peak, never below 670K, from one decoupled producer over a two-hour capture"
    }
   ],
   "lede": "One trait, three axes I was going to build many systems and did not want to solve orchestration more than once, so I made FAFO Core and Function Forge one execution model that every function runs under. A function implements one Rust trait, and a generic conductor runs it along three independent axes over Redis and PostgreSQL. design <blockquote class=\"dv-quote\" <p Orthogonal axes over named modes: a new combination is a configuration change.</p </blockquote Services trigger continuously, on queue depth or on an interval. In submit-and-exit, a producer hands generation to the GPU broker and moves on while a completion service closes the loop; I split completion out after an embedded design made producers wait on results. design <figure class=\"dv-figure\"",
   "quote": "Orthogonal axes over named modes: a new combination is a configuration change.",
   "evidence": [
    "Distributed job orchestration: one Rust trait run as a job or a service, batched by rows or GPU token budget, in-process to rented cloud GPUs, under 13 function crates.",
    "Control-plane design: 19 control actions, among them pause, scale, drain and inspect, reaching active conductors through a separate high-priority stream.",
    "High-throughput batch inference: a decoupled producer holding 670K-970K probes in flight over a two-hour capture across Blackwell GPU hosts."
   ],
   "technology_kind": "discipline"
  },
  {
   "url": "https://coreyjames.ai/technologies/distributed-systems-reliability/",
   "kind": "technology",
   "title": "Distributed-systems reliability",
   "subtitle": "Nothing waits on anything else, every component restarts independently, and the accounting balances.",
   "systems": [
    "inference-fabric",
    "agent-swarm"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "32",
     "label": "at-most-once windows written into the gap register"
    },
    {
     "value": "3,099",
     "label": "batches whose fill once blocked the broker for 17 seconds"
    },
    {
     "value": "6",
     "label": "leakage rules binding the delivery, coordination and durability planes"
    }
   ],
   "lede": "Done means delivered and acknowledged The Inference Fabric lost work silently under load. Its buffer service is a custom distributed system: producers, a durable broker and pull-based GPU consumers on separate machines, each restartable on its own, with no distributed transactions and no shared state store on the hot path. design <figure class=\"dv-figure\" aria-label=\"Items pending according to the registry against items actually in storage\" <span class=\"eyebrow\" What the broker believed against what existed</span <div class=\"dv-bars\" style=\"grid-template-columns: 8rem minmax(0, 1fr) 4.6rem\" <span Registry: pending</span <span <span class=\"bar\" style=\"width: 100%; background: var(--orange)\" </span </span <span class=\"v\" 6.67M</span <span Storage: held</span <span <span class=\"bar on\" style=\"width: 1.8%; min-width: 4px\" </span </span <span class=\"v on\" 118K</span </div </figure I traced it to a definition.",
   "quote": "“Consumed on read” was the bug, and “acknowledged on completion” was the cure.",
   "evidence": [
    "Exactly-once delivery and crash recovery: a broker whose registry showed 6.67M items pending against 118K in storage, fixed by redefining done as delivered and acknowledged.",
    "Distributed systems correctness: liveness restored after a 3,099-batch fill blocked the broker for 17 seconds, with a time budget on channel filling.",
    "Failure-domain design: delivery, coordination and durability planes bound by 6 leakage rules, so a coordinator outage leaves delivery alone.",
    "Delivery guarantees: 32 at-most-once windows written into a gap register instead of paying for exactly-once delivery."
   ],
   "technology_kind": "discipline"
  },
  {
   "url": "https://coreyjames.ai/technologies/docker/",
   "kind": "technology",
   "title": "Docker",
   "subtitle": "Containers are how my agents are sandboxed, how GPU consumers are provisioned on local, LAN and cloud hosts, and how release images are proven.",
   "systems": [
    "agent-swarm",
    "agentos",
    "fafo-core",
    "inference-fabric",
    "activekv",
    "helix",
    "fafohive",
    "auth-and-access-plane"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "10",
     "label": "image definitions for native workers, coding-CLI seats and infrastructure services"
    },
    {
     "value": "4",
     "label": "loader modes on one generic image: job, capability, agent, infrastructure"
    },
    {
     "value": "2",
     "label": "per-GPU images, one for each NVIDIA Blackwell GPU"
    }
   ],
   "lede": "A sandbox an agent cannot loosen In Agent Swarm, agents that run code need a sandbox they cannot loosen. The launcher drives the Docker Engine API from Rust to create, inspect, pause and kill agent containers. design <blockquote class=\"dv-quote\" <p Hardening is the default profile, and an agent has no switch to turn it off.</p </blockquote design <figure class=\"dv-figure\" aria-label=\"An agent image, from registry to launch\" <span class=\"eyebrow\" style=\"margin-top: 0\" A launch</span <div style=\"display: flex; flex-wrap: wrap; gap: 0.4rem 2px; margin-top: 0.7rem\" <div style=\"flex: 2 1 4.8rem; min-width: 0\" <div style=\"background: color-mix(in srgb, var(--tone) 45%, var(--surface)); display: flex; align-items: center; padding: 3px 8px; color: var(--ink); font-size: clamp(0.6rem, 2.5vw, 0.74rem); font-weight: 600; line-height: 1.15; min-height: 30px; border-radius: 4px\" pulled by digest</div",
   "quote": "Hardening is the default profile, and an agent has no switch to turn it off.",
   "evidence": [
    "Sandboxing and container hardening: agent containers driven through the Docker Engine API from Rust with all capabilities dropped, a read-only root, no root user, resource caps and egress allowlists by default.",
    "Container-based compute provisioning: one generic image with 4 loader modes that runs a function on a local, LAN or cloud GPU host with no rebuild, cloud capacity only past a fail-closed budget gate.",
    "Reproducible native builds: kernel patches rebuilt inside the exact vendor image from a clean clone and promoted only after engine and kernel hashes are read back from inside the image."
   ],
   "technology_kind": "platform"
  },
  {
   "url": "https://coreyjames.ai/technologies/evidence-gated-acceptance/",
   "kind": "technology",
   "title": "Evidence-gated acceptance",
   "subtitle": "A capability counts only when evidence shows it wired and exercised at runtime, and the gates say what is still unproven.",
   "systems": [
    "helix",
    "fafo-core",
    "auth-and-access-plane"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "55 of 55",
     "label": "Rust tests passed by the meeting tools, kept open until their runtime gates passed"
    },
    {
     "value": "47",
     "label": "integration tests that list what they leave unproven"
    },
    {
     "value": "~9,000",
     "label": "lines of hardening modules built, and kept apart from what guards requests"
    }
   ],
   "lede": "Three states, each with its own evidence AI engineering teams produce plausible claims that something works, and live tests in a real Microsoft tenant are scarce, so I set Helix a strict vocabulary. Unit tests prove a thing is implemented, a runtime trace proves it is wired, and a live session proves it works in the meeting. Every meeting action moved through those states, and nothing counted as complete until its live gate passed; the second-generation meeting tools passed every Rust test and every stage test, and I kept them open until the live gates passed. Where Microsoft's platform has no supported path, the action fails closed and says why. design <figure class=\"dv-figure\" aria-label=\"Three meeting actions sent toward the platform:",
   "quote": "A mocked backend never counts as proven live.",
   "evidence": [
    "Evidence-gated acceptance: meeting tools that passed 55 of 55 Rust tests kept open until their runtime gates passed in the meeting.",
    "Quality engineering for AI-produced work: 47 integration tests that list what they leave unproven, with failed gates kept in the history.",
    "Documentation audited against code: system dossiers re-documented from the code with drift tables, where the code wins any disagreement."
   ],
   "technology_kind": "discipline"
  },
  {
   "url": "https://coreyjames.ai/technologies/evidence-gated-api-integration/",
   "kind": "technology",
   "title": "Evidence-gated API integration",
   "subtitle": "My API integration platform treats each third-party API as a declarative unit over a generic core, with evidence for every gate.",
   "systems": [
    "fafo-core"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "~20,000",
     "label": "lines of Rust behind one generic MCP server"
    },
    {
     "value": "35",
     "label": "per-criterion check scripts with re-runnable transcripts"
    },
    {
     "value": "B0–B9",
     "label": "gated phases the build moved through"
    }
   ],
   "lede": "One generic core, one profile per API The integration platform in FAFO Core and Function Forge puts an HTTP API behind a generic MCP (Model Context Protocol) server. The generic core is built once, and each API is a declarative connectivity profile, so a new integration is a matter of configuration and probes. design <figure class=\"dv-figure\" aria-label=\"Three API profiles, each eight declarative sections, sitting on one generic core\" <div style=\"display: flex; flex-direction: column; gap: 6px\" <div style=\"display: grid; grid-template-columns: minmax(4.5rem, 4.5rem) minmax(4rem, 1fr); gap: 10px; align-items: center\" <span class=\"lbl\" API one</span <div style=\"display: flex; gap: 3px\" <i style=\"flex: 1; height: 18px; border-radius: 3px; background: var(--tone)\" </i <i style=\"flex: 1; height: 18px; border-radius: 3px; background: var(--tone)\" </i <i style=\"flex: 1; height:",
   "quote": "A field in the documentation is a claim, and a field in a successful response is a fact.",
   "evidence": [
    "Tool synthesis and governed API integration: about 20,000 lines of Rust behind one generic MCP server, each API a declarative connectivity profile.",
    "Evidence-gated acceptance: a field counts only once a successful call returns it, with 35 per-criterion acceptance scripts and 23 of 23 items closed.",
    "API validation gates: connect, auth, list, get and write must pass before any tool is authored, and negative catalogs show the gate rejecting."
   ],
   "technology_kind": "discipline"
  },
  {
   "url": "https://coreyjames.ai/technologies/evidence-grounded-llm-output/",
   "kind": "technology",
   "title": "Evidence-grounded LLM output",
   "subtitle": "A model in my systems may narrate evidence it was handed; it may not produce evidence.",
   "systems": [
    "fafohive"
   ],
   "technologies": [],
   "stats": [],
   "lede": "Compute first, narrate second Engineers act on a model's explanation of how code works, and a fluent explanation can include call paths that do not exist. In FAFOHive I decided the explainer would compute first and narrate second, with that order enforced in code: explain code path does every structural step before a language model is called, using the parser-built code graph and the index, so every structural statement in an answer comes from a computation that already ran. Each request is pinned to one graph generation, so the path, the code and the narrative all describe the same version. design <figure class=\"dv-figure\" aria-label=\"Three graph generations drawn as stacked layers, with a request pinned to exactly one of them\" <div",
   "quote": "A caveat attached to a plausible guess is the first thing a reader stops seeing.",
   "evidence": [
    "Grounded LLM output: a code explainer that computes the graph path before calling a model and returns a typed coverage-incomplete result instead of a guess.",
    "Code intelligence and static analysis: answers drawn from a parser-built code graph pinned to one generation, with file and line citations.",
    "Multi-vendor LLM integration: one contract binding every narration provider, local open models included, so a model swap changes prose and never structure."
   ],
   "technology_kind": "discipline"
  },
  {
   "url": "https://coreyjames.ai/technologies/faiss/",
   "kind": "technology",
   "title": "FAISS",
   "subtitle": "FAISS is a reference and a bake-off participant in my vector work; my own GPU store builds deterministic indexes and reports their health.",
   "systems": [
    "fafohive",
    "inference-fabric",
    "capabilities-model"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "3",
     "label": "index families, each chosen for the set it held"
    },
    {
     "value": "7B",
     "label": "dense model in FP8 whose answers the pipeline searched"
    },
    {
     "value": "1",
     "label": "bulk update per build writes index positions back"
    }
   ],
   "lede": "Searching for the gaps in what a model knew Inference Fabric grew out of a research pipeline I ran first, and FAISS was the vector engine in both. The pipeline interrogated a model through vLLM, embedded the answers with an embedding model, grouped them into concept clusters of question-and-answer units, and searched for gaps in what the model knew. FAISS ran the batch nearest-neighbour search that found those gaps, rebuilt the GPU indexes after each restructuring pass, and fed the centroid updates. The knowledge base reached hundreds of thousands of clusters and millions of units. I picked the index type per set, because the centroids, the answer embeddings and the candidates differ by orders of magnitude in size and in",
   "quote": "I use a library where it solves the problem at hand and replace it when the architecture outgrows it.",
   "evidence": [
    "Vector search and ANN indexes: inverted-file, HNSW and flat FAISS indexes chosen per set for hundreds of thousands of cluster centroids and millions of answer embeddings from a 7B model.",
    "PostgreSQL bulk data movement: vectors read out with binary COPY and parsed directly, staged in an unlogged table, and index positions written back in one bulk update per build.",
    "Architecture evolution: a FAISS index service retired for a GPU-resident vector store once its SQL and Python round trip set the cost, keeping the neighbour distances the CUDA health kernels read."
   ],
   "technology_kind": "datastore"
  },
  {
   "url": "https://coreyjames.ai/technologies/fastapi/",
   "kind": "technology",
   "title": "FastAPI",
   "subtitle": "The OAuth authorization server and the earlier Python dispatch layer are FastAPI.",
   "systems": [
    "auth-and-access-plane",
    "fafo-core"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "4",
     "label": "Uvicorn workers on uvloop behind NGINX"
    },
    {
     "value": "3",
     "label": "vendors' assistants authenticating against one server"
    },
    {
     "value": "2",
     "label": "FastAPI apps: the authorization server and the operator console"
    }
   ],
   "lede": "An OAuth server for AI assistants Auth and access plane exists because I wanted commercial AI assistants to reach my private tool estate through standard OAuth, with a person approving every grant. I built the authorization server as a FastAPI application. Access tokens are RS256-signed JWTs. I put TLS, rate limits and process sandboxing in NGINX and systemd, so the front end protects the application independently of the application's own code. design <figure class=\"dv-figure\" aria-label=\"What the authorization server serves, what sits in front of it, and where its state lives\" <div class=\"arch-planes\" style=\"--arch-cols: 1fr 1.4fr 1fr\" <div class=\"plane soft\" <span class=\"eyebrow\" In front</span <div class=\"objs\" <div class=\"obj\" <strong NGINX</strong <span class=\"d\" terminates TLS, rate-limits per endpoint</span </div <div class=\"obj\" <strong",
   "quote": "I made the consent screen the control point, because it is the one place a person sees exactly which client is asking for exactly what.",
   "evidence": [
    "OAuth and identity architecture: a FastAPI authorization server with PKCE, consent, token, revocation, key set and discovery endpoints and RS256-signed JWTs, 4 Uvicorn workers behind NGINX.",
    "Interoperability engineering: 3 vendors' AI assistants authenticating against one server despite reading discovery, ordering consent and caching client identity differently.",
    "Application security hardening: generated API documentation turned off on the operator console, the health endpoint cut to a bare status, and a registration lock reverted when it broke every client.",
    "Prototyping to Rust systems engineering: a FastAPI dispatch service proved the idea and was rebuilt in Rust as a control plane, admission controller and gateway."
   ],
   "technology_kind": "framework"
  },
  {
   "url": "https://coreyjames.ai/technologies/federated-compute-provisioning/",
   "kind": "technology",
   "title": "Federated compute provisioning",
   "subtitle": "One call stands up GPU capacity on a local card, a LAN workstation over mutual TLS, or rented cloud spot capacity, behind a fail-closed daily budget.",
   "systems": [
    "fafo-core",
    "inference-fabric",
    "agent-swarm"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "15",
     "label": "MCP actions on the node-management tool"
    },
    {
     "value": "17,303",
     "label": "lines of Rust in the provisioning substrate, across 26 files"
    },
    {
     "value": "3",
     "label": "providers behind one trait: local, LAN and cloud"
    }
   ],
   "lede": "One call, wherever the GPU is FAFO Core and Function Forge needed compute from wherever I had it: the workstation, a spare machine on the LAN, or a rented cloud GPU up to datacentre Blackwell. I made location a parameter of one MCP call. Underneath is one Rust provider trait, implemented for local Docker, LAN Docker daemons reached over mutual TLS, and RunPod for cloud pods. I kept one implementation of ports, health, events and spend, and every family of workloads composes it. design <figure class=\"dv-figure\" aria-label=\"Three providers standing on one trait and one set of shared machinery\" <div style=\"display: grid; grid-template-columns: repeat(3, minmax(0, 1fr)); gap: 6px; align-items: end\" <div style=\"border-radius: 8px 8px 0 0; background: var(--navy-2); color: var(--on-navy); padding:",
   "quote": "The estate is a handful of machines, and the scheduler I needed was a budget.",
   "evidence": [
    "Cloud GPU provisioning with cost controls: one MCP call places capacity on a local card, a LAN host over mutual TLS or a cloud pod, behind a daily budget only a person sets, checked before anything exists.",
    "Rust systems engineering: one provider trait with three implementations over shared port leases, health, events and spend, 17,303 lines across 26 files.",
    "Zero-trust and zero-inbound networking: cloud pods dial back to the private network so no GPU host opens an inbound port, and LAN hosts join through an 11-step onboarding with rollback.",
    "MCP server design: a node-management tool of 15 actions that reads each engine's declared token capacity, so cards of different sizes drain one backlog."
   ],
   "technology_kind": "discipline"
  },
  {
   "url": "https://coreyjames.ai/technologies/ffmpeg/",
   "kind": "technology",
   "title": "FFmpeg",
   "subtitle": "FFmpeg frames a headless Linux desktop as H.264 for screen sharing into Teams meetings and drives the media studio's transforms.",
   "systems": [
    "helix",
    "fafohive"
   ],
   "technologies": [],
   "stats": [],
   "lede": "Screen sharing for an AI colleague Helix needed a way for the digital employee to show its work in a Teams meeting. I decided it should share a real screen: a headless Linux desktop with a virtual display, a window manager, Chromium and a terminal, captured by FFmpeg's X11 grabber and encoded to H.264. I tuned the encoder for slides and terminal text, and for the viewer who joins late. design <figure class=\"dv-figure\" aria-label=\"The screen-share stream: few frames, a keyframe every few, stream headers on each keyframe\" <span class=\"eyebrow\" One second of the stream, illustrative</span <div style=\"display: flex; align-items: flex-end; gap: 3px; margin-top: 0.8rem\" <span style=\"flex: 1; display: flex; flex-direction: column; align-items: center; gap: 2px\" <i style=\"width: 70%; height: 5px;",
   "quote": "I treat an agent-facing tool as an attack surface first and a convenience second.",
   "evidence": [
    "Video encoding for screen sharing: a headless Linux desktop encoded to H.264 for slides and terminal text and for late joiners, shared into Teams meetings.",
    "Sandboxing agent tools: a fixed menu of typed media transforms whose FFmpeg arguments are written by code, with no codec, filter or shell text accepted from the agent.",
    "Cross-host file delivery: inputs staged onto the machine that runs the job and outputs hash-checked at the destination."
   ],
   "technology_kind": "platform"
  },
  {
   "url": "https://coreyjames.ai/technologies/garnet/",
   "kind": "technology",
   "title": "Garnet",
   "subtitle": "A Redis-compatible store evaluated for the memory service's hot path.",
   "systems": [
    "fafohive"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "242",
     "label": "lines of Rust run the managed instance from start to stop"
    }
   ],
   "lede": "A Redis-protocol tier in front of PostgreSQL The memory service in FAFOHive keeps PostgreSQL as its source of truth and a Redis-protocol tier in front of it. design <figure class=\"dv-figure\" aria-label=\"Reads served at the hot tier, writes queued there and drained to PostgreSQL later\" <div style=\"display: grid; gap: 0.7rem\" <div style=\"display: grid; grid-template-columns: minmax(0, 7rem) minmax(0, 1fr); gap: 0.6rem; align-items: center\" <span class=\"lbl\" Vector search</span <div style=\"display: flex; gap: 3px\" <span style=\"flex: 2; height: 24px; border-radius: 5px; background: var(--rule); display: flex; align-items: center; padding: 0 5px; font-size: 0.7rem; font-weight: 600; color: var(--ink); white-space: nowrap; overflow: hidden\" request</span <span style=\"flex: 3; height: 24px; border-radius: 5px; background: var(--tone); display: flex; align-items: center; padding: 0 5px; font-size: 0.7rem; font-weight: 600; color: var(--on-navy); white-space:",
   "quote": "The backing server is a deployment choice, not a code change.",
   "evidence": [
    "Redis-protocol caching tiers: a hot tier for vector search, cached results and an observation write queue in front of PostgreSQL, with the backing server a deployment choice.",
    "Rust systems engineering: a 242-line lifecycle module that starts a managed Garnet instance on localhost with its own port and checkpoints, waits for PING and stops with the service."
   ],
   "technology_kind": "datastore"
  },
  {
   "url": "https://coreyjames.ai/technologies/gaussian-kernel-cluster-analysis/",
   "kind": "technology",
   "title": "Gaussian-kernel cluster analysis",
   "subtitle": "A per-cluster length scale from a histogram median, then potential depth, curvature, escape probability, superposition, interference and entanglement as field metrics over an embedding cluster.",
   "systems": [
    "inference-fabric"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "256",
     "label": "bins in the shared-memory histogram that finds the median distance"
    },
    {
     "value": "0.4%",
     "label": "resolution of that median, held in 10 KB of shared memory"
    },
    {
     "value": "2,000",
     "label": "members, the most the CPU spectral metrics will report on"
    }
   ],
   "lede": "A length scale from a histogram median One family of my cluster metrics treats a cluster of embeddings as a field rather than a point set. Each member contributes a Gaussian kernel of its distance, the width of the kernel is a per-cluster length scale, and the shape of the resulting potential describes the cluster. The family runs in the Inference Fabric's CUDA engine and is told in Physics as a lens on embeddings. The length scale is a constant times the median pairwise distance of the cluster, clamped to a documented range. A per-cluster scale makes the metrics independent of the embedding model's units. A tiled kernel bins every distance into a shared-memory histogram and reads the midpoint from",
   "quote": "I left three metrics off the GPU until they can run without a hidden cap.",
   "evidence": [
    "Embedding analytics and cluster metrics: Gaussian-kernel field metrics per cluster (potential depth, curvature, escape probability, superposition, interference, entanglement) on a per-cluster length scale.",
    "CUDA kernel development: the median pairwise distance read from a 256-bin shared-memory histogram at 0.4% resolution in 10 KB, and entanglement tiled over the upper triangle with no Gram matrix.",
    "Bounded numerical methods: three Gram-matrix spectral metrics kept as CPU reference code that reports nothing above 2,000 members instead of sampling."
   ],
   "technology_kind": "discipline"
  },
  {
   "url": "https://coreyjames.ai/technologies/git/",
   "kind": "technology",
   "title": "Git",
   "subtitle": "My governance platform reads git as evidence: witness, task and decision commits, authorship trailers, and the rule that every commit is pushed and nothing is rewritten.",
   "systems": [
    "agentos",
    "agent-swarm"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "~1,360",
     "label": "lines of Rust in the commit hook, tested against fake git clients"
    }
   ],
   "lede": "Commits as an output of AgentOS AgentOS runs teams of coding agents that finish tasks constantly, often at the same moment, in the same repository. I wanted every finished task to leave a commit I could trace to its work order. I also wanted no agent touching git directly. So git became an output of the platform: agents never run raw git or push. When an agent finishes a task, a lifecycle hook commits the active work order's own project directory, and only that directory, as a tagged commit that names the work order and the task, so the history is searchable by the unit of work. design <figure class=\"dv-figure\" aria-label=\"One work order's history as commits coloured by kind\" <div",
   "quote": "Commits mark the work, carry attribution and stay out of agents' direct reach.",
   "evidence": [
    "Version control as AI governance: tagged commits per finished task, decision and evidence, written by a lifecycle hook so agents never run git or push.",
    "Concurrency control: commits scoped to one work order's directory under a shared file lock with a timeout, failing open with a report.",
    "Rust systems engineering: a ~1,360-line commit hook tested against fake git clients, so every failure path is exercised without a real repository."
   ],
   "technology_kind": "platform"
  },
  {
   "url": "https://coreyjames.ai/technologies/gitlab/",
   "kind": "technology",
   "title": "GitLab",
   "subtitle": "Self-hosted GitLab is where my agents open merge requests they are not allowed to merge, and where discovered defects are filed as issues.",
   "systems": [
    "agent-swarm",
    "fafohive"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "2",
     "label": "end-to-end runs from a worker's edit to an opened merge request"
    },
    {
     "value": "0",
     "label": "agent commits or merge requests against the main repository"
    }
   ],
   "lede": "Merge requests agents cannot merge Agent Swarm needed to show that a coding agent on a local model could do real repository work without ever being able to merge it. I decided the merge request would be the boundary and GitLab, self-hosted, would be where a person sees the result. A worker agent edits, tests, commits and pushes to its own branch from a throwaway container. A separate, long-lived gatekeeper agent is the only holder of the repository credential, so a compromised or confused worker has nothing to leak; it checks the worker's request and opens the merge request through the GitLab API. The story A coding agent that never holds the keys tells it in full. design <figure class=\"dv-figure\"",
   "quote": "I made the merge request the line agents cannot cross: they propose, a person merges.",
   "evidence": [
    "Credential isolation for coding agents: a worker that edits, tests and pushes its own branch and a gatekeeper that alone holds the repository credential; 2 runs to merge request, 0 agent commits to main.",
    "MCP tool design: one action-dispatched GitLab tool for issues, comments, labels, local git and merge requests, with a state that hands a problem back to a person."
   ],
   "technology_kind": "platform"
  },
  {
   "url": "https://coreyjames.ai/technologies/governed-ai-assisted-software-engineering/",
   "kind": "technology",
   "title": "Governed AI-assisted software engineering",
   "subtitle": "Written definitions of done, builders and reviewers from different model families, intake and promotion procedures, and evidence that decides.",
   "systems": [
    "agentos",
    "agent-swarm",
    "fafohive",
    "fafo-core",
    "inference-fabric",
    "activekv",
    "capabilities-model"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "3 weeks",
     "label": "or less for the native C++ port of ActiveKV under a seven-criterion definition of done"
    },
    {
     "value": "24",
     "label": "performance promotions through the procedure in four days"
    },
    {
     "value": "60+",
     "label": "locked decisions in the Agent Swarm master plan before parallel work"
    }
   ],
   "lede": "Most of the code behind the systems on this site was written by AI coding agents. I lead that work as an architect: I keep the agents that build apart from the agents that judge, and make the calls when the evidence is disputed. I write the definition of done, the intake standard and the promotion procedure before work starts, and each new ruling becomes standing doctrine. The method is the story Directing AI coding agents at program scale. Taking the memory out of the model AgentOS started from a diagnosis. Long agent runs drift because the lead agent has to hold the procedure, the plan, every teammate's state and every piece of evidence in its context, and past some",
   "quote": "An agent's report that it is done is a claim; the system closes work on evidence a separate seat has checked.",
   "evidence": [
    "AI-assisted engineering methodology: definitions of done, intake screens and promotion procedures written before work starts, with builders and judges from different model families.",
    "C++ and native ports with parity proof: a Python-to-C++ engine port in under 3 weeks against a seven-criterion definition of done, then 24 performance promotions in four days.",
    "Evidence-gated acceptance: an integration platform held open after agents reported it finished, until 23 of 23 close items closed under independent review.",
    "Technical leadership of agent teams: a master plan of 60+ locked decisions, gatekeepers that never built what they judged, and a decision ledger of 160 entries with 24 of my rulings."
   ],
   "technology_kind": "discipline"
  },
  {
   "url": "https://coreyjames.ai/technologies/gpu-admission-control-and-co-residency/",
   "kind": "technology",
   "title": "GPU admission control and co-residency",
   "subtitle": "Two models on one GPU, with the second admitting work against measured memory and refusing with a number: a 0.6B router beside a 30B model, through a 2,048-client burst.",
   "systems": [
    "helix",
    "inference-fabric",
    "capabilities-model"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "2,740",
     "label": "MiB, the router's whole footprint beside the resident model"
    },
    {
     "value": "85.9/s",
     "label": "requests served through the 2,048-client burst"
    },
    {
     "value": "45.5/s",
     "label": "short requests sustained"
    }
   ],
   "lede": "A router beside a 30B model Capabilities model had to run on a Blackwell GPU whose memory belonged to a 30-billion-parameter model that stayed resident and serving. Agents call the discovery model before most actions, so many would call it at once, and a wrong answer under load would be worse than a slow one. I gave it a fixed memory budget and made two thousand concurrent clients an acceptance criterion from the start. design <blockquote class=\"dv-quote\" <p I set the acceptance numbers before the engine exists so the result cannot be reframed afterwards.</p </blockquote The engine admits work against the memory it has measured, so overload becomes a queue and then a refusal and never a corrupted answer. Before",
   "quote": "I set the acceptance numbers before the engine exists so the result cannot be reframed afterwards.",
   "evidence": [
    "GPU co-residency and admission control: a 0.6B router in 2,740 MiB beside a 30B serving model, admitting work against measured memory and refusing with the shortfall and a retry hint.",
    "Load testing at concurrency: a ladder to 2,048 clients with abort conditions at every rung, the burst served at 85.9 requests per second with none failed, rejected or corrupted.",
    "Honest performance reporting: mixed traffic reported at 6.9 requests per second against a pre-registered target of 200 rather than a flattering count of about 14.",
    "High-throughput batch inference: admission in front of TensorRT-LLM's in-flight batcher with a minimum-batch token gate and backpressure counted at the GPU."
   ],
   "technology_kind": "discipline"
  },
  {
   "url": "https://coreyjames.ai/technologies/gpu-inference-engine-engineering/",
   "kind": "technology",
   "title": "GPU inference engine engineering",
   "subtitle": "I built a batched continuous-decode engine with paged key-value memory, admission control, canary-gated binding and typed refusals, and I tried the vendor's industrial stack first and closed it on measurements.",
   "systems": [
    "capabilities-model"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "518 µs",
     "label": "removed per token by the on-GPU decode loop, up to 696 under load"
    },
    {
     "value": "13.4×",
     "label": "faster prefill in 256-token chunks, identical answers"
    },
    {
     "value": "503 MiB",
     "label": "CUDA context, reported apart so admission stays honest"
    },
    {
     "value": "2.53×",
     "label": "less device memory with NVFP4 weights, about 5 percent slower"
    }
   ],
   "lede": "Measuring the industrial path first Capabilities model is a 0.6-billion-parameter tool-discovery model that had to serve two thousand concurrent agents. It had only the memory a resident 30-billion-parameter model left free on one NVIDIA Blackwell GPU. I had the vendor's industrial stack tried first. Its weight conversion corrupted some tensors by up to a thousand times. That is Trying the industrial path first. design <figure class=\"dv-figure\" aria-label=\"The vendor's industrial stack, measured first: requests per second with the card to itself and beside the 30B model\" <span class=\"eyebrow\" TensorRT-LLM · requests per second</span <div class=\"dv-bars\" <span Card to itself</span <span class=\"bar\" style=\"width: 100%\" </span <span class=\"v\" 492</span <span Beside the 30B model</span <span <span class=\"bar on\" style=\"width: 11.4%\" </span </span <span",
   "quote": "I build custom only after measuring the standard option.",
   "evidence": [
    "GPU inference optimisation: a purpose-built Rust and CUDA decode engine for a 0.6B tool-discovery model, with the decode loop as one CUDA graph removing 518 microseconds per token.",
    "Deterministic GPU computation: one block per output row and fixed reduction trees, passing 12 of 12 bit-identity gates and 2,345 of 2,345 rank-one results across shuffled batches.",
    "TensorRT and TensorRT-LLM engineering: the vendor stack measured first at 492 requests per second with the card to itself and 56 beside the serving model, before building custom.",
    "LLM quantization: NVFP4 weights using 2.53 times less device memory than FP8 at about 5 percent slower."
   ],
   "technology_kind": "discipline"
  },
  {
   "url": "https://coreyjames.ai/technologies/gpu-memory-management/",
   "kind": "technology",
   "title": "GPU memory management",
   "subtitle": "ActiveKV inverts who owns memory: history in pinned host RAM, the GPU a budgeted working set.",
   "systems": [
    "inference-fabric",
    "activekv"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "147 MiB",
     "label": "recurrent-layer state per context, fixed whatever the length"
    },
    {
     "value": "2 GiB",
     "label": "of pinned host memory per 32K-token history"
    },
    {
     "value": "16",
     "label": "dense layers sharing one device arena"
    },
    {
     "value": "0",
     "label": "CUDA allocations after the first second of a trace, down from about 4,200"
    }
   ],
   "lede": "Inverting who owns memory ActiveKV began with a constraint I did not accept. Stock vLLM keeps a request's whole key-value cache on the GPU, so on a 32 GB Intel Arc Pro GPU the card decides how much context a model can hold. I inverted who owns memory and gave the device a stated budget, so the operator chooses the trade-off. design <figure class=\"dv-figure\" aria-label=\"Who owns each kind of memory after the inversion\" <div class=\"dv-legend\" <div <i style=\"width: 150px; background: var(--tone)\" </i <span class=\"lbl\" Pinned host memory: the authoritative copy of every context's attention history</span </div <div <i style=\"width: 52px; background: color-mix(in srgb, var(--tone) 45%, var(--surface))\" </i <span class=\"lbl\" GPU: a bounded, budgeted working set</span </div <div <i style=\"width: 22px;",
   "quote": "Memory is a design decision, not a default.",
   "evidence": [
    "KV-cache offload for LLM inference: pinned host memory as the copy of record and the GPU as a budgeted page arena, with 2 GiB of host memory per 32K-token history.",
    "Latency engineering under concurrency: reclaimed device memory spent to cut inter-token latency from 273.58 to 141.48 ms on long prompts with four concurrent requests.",
    "GPU memory management: staging leases released only on completed fences, quarantine on an unknown fence outcome, and a host-pool fit that prints its own formula.",
    "TensorRT and TensorRT-LLM engineering: a throughput runtime with 0 CUDA allocations after the first second of a trace, down from about 4,200."
   ],
   "technology_kind": "discipline"
  },
  {
   "url": "https://coreyjames.ai/technologies/gpu-numerical-kernel-design/",
   "kind": "technology",
   "title": "GPU numerical kernel design",
   "subtitle": "Kernels with fixed-order reductions, one block per output row, no K-split tiling: determinism by construction.",
   "systems": [
    "inference-fabric",
    "capabilities-model"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "38",
     "label": "per-cluster metrics, every family with a CPU reference"
    },
    {
     "value": "12 of 12",
     "label": "bit-identity gates across batch compositions in the decoder"
    },
    {
     "value": "256",
     "label": "bins in the histogram that yields each Gaussian width"
    },
    {
     "value": "3",
     "label": "Lloyd iterations, fixed into the silhouette's definition"
    }
   ],
   "lede": "Per-cluster diagnostics no library offered Inference Fabric stores clustered embeddings, and a clustered embedding space needs constant quality checks: is a cluster tight, drifting, bimodal, contaminated by outliers, redundant with a neighbour? The GPU libraries I had offered search and whole-dataset clustering, with no per-cluster diagnostics, and none targeted CUDA 13 on Blackwell from Rust. I decided to write the kernels, and I set their numerical rules before any were written. The engine is called through the raw CUDA driver API and compiled to native Blackwell binaries. It targets Blackwell only and computes in f32 with no tensor-core path. Its per-cluster metrics fall into a few families. design <figure class=\"dv-figure\" aria-label=\"One cluster and the five families of metrics read from",
   "quote": "I left diagnostics unclamped, because a metric forced into range hides the failure it exists to catch.",
   "evidence": [
    "CUDA kernel development: 38 per-cluster metrics in five families for Blackwell, called from Rust through the raw CUDA driver API, with every member used and nothing sampled.",
    "Numerical stability in f32: Welford updates per thread with Chan merges across warps, a 256-bin histogram median, and every family checked against a CPU twin within a relative 1e-4.",
    "Deterministic GPU computation: one block per output row, fixed shuffle trees and no K-split tiling, passing 12 of 12 bit-identity gates across batch compositions."
   ],
   "technology_kind": "discipline"
  },
  {
   "url": "https://coreyjames.ai/technologies/gpu-profiling-and-tracing/",
   "kind": "technology",
   "title": "GPU profiling and tracing",
   "subtitle": "I instrument ActiveKV down to the runtime call level and I measure the instrument: a profiler that serialised the copy engine it was observing got its verdict retracted in the plan.",
   "systems": [
    "activekv"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "4",
     "label": "capture levels, from runner phases to every runtime call"
    },
    {
     "value": "0.21",
     "label": "copy overlap at best with timing events on, down to 0.02"
    },
    {
     "value": "1.09",
     "label": "the same overlap at best with them off, down to 0.79"
    }
   ],
   "lede": "Capture levels chosen per run ActiveKV is only faster if I can see where each decode step spends its time, on the host and on the device, and the act of looking changes the answer. I decided to build the instrument and then measure the instrument. I directed the build of a step-profiling suite with capture levels chosen per run. design <figure class=\"dv-figure\" aria-label=\"One decode step seen at four capture levels, each finer than the last\" <div style=\"display: grid; grid-template-columns: 9.5rem minmax(0, 1fr); gap: 0.6rem 1rem; align-items: center\" <span class=\"lbl\" <strong 1 · Lowest</strong <br runner phases</span <div style=\"display: flex; gap: 2px; height: 16px\" <span style=\"flex: 0.70; border-radius: 3px; background: var(--tone)\" </span <span style=\"flex: 1.77; border-radius: 3px; background: color-mix(in srgb,",
   "quote": "I removed automatic verdicts from the comparison output, because a profiler should collect and the engineer should judge.",
   "evidence": [
    "GPU profiling and tracing: a step profiler for ActiveKV on Intel Arc with 4 capture levels, from runner phases to every Unified Runtime call, and token-life views from scheduler to client.",
    "Measurement integrity: a profiler shown to serialise the copy engine, with copy overlap 0.02 to 0.21 with timing events on against 0.79 to 1.09 off, and the verdict retracted.",
    "LD_PRELOAD symbol interposition: runtime calls intercepted by a flat-memory shim when the vendor tracing path leaked, so several captures could run at once."
   ],
   "technology_kind": "discipline"
  },
  {
   "url": "https://coreyjames.ai/technologies/grafana/",
   "kind": "technology",
   "title": "Grafana",
   "subtitle": "Dashboards are how I captured the numbers on this site.",
   "systems": [
    "inference-fabric",
    "auth-and-access-plane",
    "agentos",
    "fafo-core",
    "capabilities-model"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "~137",
     "label": "metrics exported by the broker"
    },
    {
     "value": "31",
     "label": "panels on the broker's dashboard"
    },
    {
     "value": "~203,000",
     "label": "hidden-state extractions in a single test run"
    }
   ],
   "lede": "Dashboards built around the measures Inference Fabric made claims about GPU efficiency that I wanted to prove from a screen, so I built its dashboards around the measures that justify the design. The panels show tokens per second split into prefill and decode, padding waste, shape switches, key-value cache hit rate, the broker's lanes and cold tier, probes and extractions per second, and a token-accounting difference that should always read zero. I chart domain measures first, because padding waste and token-accounting drift say more about a GPU pipeline than host load does, and I built each fabric dashboard alongside the feature it measured, so a change was visible the day it landed. Every fabric figure on this site comes from",
   "quote": "I decide what to measure as part of the design, and I build the instruments that let me defend each number.",
   "evidence": [
    "Observability and alerting: dashboards built around domain measures, ~137 broker metrics on 31 panels, file-based target discovery and Alertmanager routing to SMS.",
    "GPU pipeline metrics: tokens per second, padding waste, cache hit rate and a token-accounting difference that reads zero, with 163,000 tokens per second read from the panels.",
    "Cost attribution for AI work: per-seat cost and cache reuse for a work order read from PostgreSQL rollups, cache reuse spanning 43% to 97% across seats."
   ],
   "technology_kind": "platform"
  },
  {
   "url": "https://coreyjames.ai/technologies/grammar-constrained-decoding/",
   "kind": "technology",
   "title": "Grammar-constrained decoding",
   "subtitle": "A grammar compiled from the tool registry constrains the decoder so that names outside the catalog cannot be produced.",
   "systems": [
    "capabilities-model"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "172 µs",
     "label": "per token cheaper than unconstrained decoding"
    },
    {
     "value": "5.58",
     "label": "extra round trips per query in the old no-repeat loop"
    },
    {
     "value": "33–47%",
     "label": "what the industrial stack's workaround cost"
    }
   ],
   "lede": "A grammar compiled from the tool registry Capabilities model answers an agent's discovery call with a ranked list of tool pointers. A small model can produce a plausible tool name that does not exist, and an agent that calls a fictional tool fails slowly and confusingly. I decided validity belonged in decoding. I also decided the constraint should make decoding cheaper. The grammar compiles from the tool registry, through the same frozen contract the evaluation scores against, into a trie over the model's own token ids. One compiled source feeds both the evaluation constraint and the serving constraint, so what was measured is what is served, and a registry change regenerates the grammar along with the training data. design <figure",
   "quote": "I treat a constraint as information the hardware can use, and I put guarantees where they can be enforced, with their exact scope stated.",
   "evidence": [
    "Constrained decoding for LLMs: a grammar compiled from the tool registry into a trie over token ids, so a tool name outside the catalog has no edge to take and cannot be produced.",
    "CUDA kernel development: masking in the sampling kernel with no-repeat counts on trie edges and the trie in constant memory, making decoding 172 microseconds per token cheaper than unconstrained.",
    "Inference serving architecture: no-repeat moved from a server-side loop costing 5.58 extra round trips per query to one on-device decrement per completed tool."
   ],
   "technology_kind": "discipline"
  },
  {
   "url": "https://coreyjames.ai/technologies/graphql/",
   "kind": "technology",
   "title": "GraphQL",
   "subtitle": "A typed Rust client for a cloud GPU provider's GraphQL API.",
   "systems": [
    "fafo-core"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "~2,400",
     "label": "lines across the client, query and type modules"
    }
   ],
   "lede": "A typed client for a GPU provider GraphQL appears in one place: the cloud GPU provider integration inside the provisioning layer of my execution substrate, FAFO Core and Function Forge. I have a typed Rust client for that provider's GraphQL API. design <figure class=\"dv-figure\" aria-label=\"The provider's API surface the typed client covers, with pod lifecycle taken over REST\" <span class=\"eyebrow\" The client, across the provider's API</span <div style=\"display: flex; gap: 3px; margin-top: 0.8rem\" <span style=\"flex: 1.3; min-width: 0; height: 26px; border-radius: 5px; background: var(--tone); opacity: 1\" </span <span style=\"flex: 1; min-width: 0; height: 26px; border-radius: 5px; background: var(--tone); opacity: 0.55\" </span <span style=\"flex: 1; min-width: 0; height: 26px; border-radius: 5px; background: var(--tone); opacity: 0.55\" </span <span style=\"flex: 1; min-width: 0;",
   "quote": "I chose REST for the pod path where the provider's REST interface was simpler, instead of keeping GraphQL for its own sake.",
   "evidence": [
    "Typed API clients in Rust: a ~2,400-line typed client for a cloud GPU provider's GraphQL API, with errors mapped through their field paths to typed failures.",
    "Resilient integration with paid APIs: bounded retry with capped exponential backoff, and REST chosen for the pod path where it was the simpler interface."
   ],
   "technology_kind": "protocol"
  },
  {
   "url": "https://coreyjames.ai/technologies/h-264/",
   "kind": "technology",
   "title": "H.264",
   "subtitle": "H.264 framing from a headless Linux desktop to the Windows media bridge, so an AI meeting attendee can share a terminal or browser as it works.",
   "systems": [
    "helix"
   ],
   "technologies": [],
   "stats": [],
   "lede": "Screen sharing through Teams' own path Helix puts a digital employee in Teams meetings, and people wanted to watch it work: a browser page it was reading, a terminal it was typing into. I decided the employee would share a real screen through Teams' own screen-sharing path, with H.264 as the video format end to end. A headless Linux desktop (virtual display, window manager, Chromium, terminal) is captured and encoded by FFmpeg as an H.264 elementary stream. The employee can share a browser, a terminal or the whole desktop, and stop cleanly. Terminal text is typed at a pace people can follow, faster for long outputs so large updates finish. design <figure class=\"dv-figure\" aria-label=\"A shared screen's path: the Linux container,",
   "quote": "I picked a low frame rate on purpose, because the content is text and the bandwidth is better spent on sharpness.",
   "evidence": [
    "Microsoft Teams real-time media: an AI participant sharing a browser, terminal or desktop into Teams as H.264 over the existing authenticated meeting connection.",
    "Binary wire protocol design: a small frame contract carrying one H.264 access unit per frame between a Rust voice engine and a C# media bridge, cut on access-unit boundaries.",
    "Video encoding for legibility: a low frame rate and stream headers repeated at every keyframe, so a late joiner or reconnected bridge starts decoding within a couple of seconds."
   ],
   "technology_kind": "protocol"
  },
  {
   "url": "https://coreyjames.ai/technologies/handlebars/",
   "kind": "technology",
   "title": "Handlebars",
   "subtitle": "Handlebars templates drive the function generator's fourteen-file output.",
   "systems": [
    "fafo-core"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "7 of 14",
     "label": "function crates in the estate carry the generator's fingerprints"
    }
   ],
   "lede": "A generator agents can call FAFO Core and Function Forge had a gap I wanted closed: agents could call tools but could not add one, and every new capability meant a person wiring a crate into the gateway, the orchestrator and the result path by hand. I built Function Forge, a generator that lets an agent author a new function, and Handlebars is its template engine. The generator is a Rust crate exposed as an MCP (Model Context Protocol) tool. From one function specification (name, parameters, data source, flags) it renders a crate. design <figure class=\"dv-figure\" aria-label=\"The generated crate: eight framework files the author may not change and six files where the author writes\" <span class=\"eyebrow\" The rendered crate</span <div",
   "quote": "Templates own everything structural and authors write only inside a bounded zone, which keeps agent-written code inside the platform's write-path architecture.",
   "evidence": [
    "Code generation and metaprogramming: a Rust generator exposed as an MCP tool that renders a function crate from one specification, with fixed framework files and a sandboxed developer zone.",
    "Tool synthesis under governance: one operation that wires gateway, control plane and completion service with rollback and link-time registration; 7 of 14 function crates carry the generator's fingerprints."
   ],
   "technology_kind": "framework"
  },
  {
   "url": "https://coreyjames.ai/technologies/hidden-state-extraction/",
   "kind": "technology",
   "title": "Hidden-state extraction",
   "subtitle": "The Inference Fabric's runtime has a single-pass hidden-state extraction mode with an empirical, fail-closed tensor-semantics detector.",
   "systems": [
    "inference-fabric"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "~203,000",
     "label": "hidden-state extractions in one run through the broker"
    },
    {
     "value": "10.8M",
     "label": "tokens in that run"
    },
    {
     "value": "4,096",
     "label": "values per probe vector, up to 524,288 tokens per pass"
    }
   ],
   "lede": "One forward pass, no generation Inference Fabric was built for a distillation workload that needs a model's internal representation of every example, at dataset scale. Serving stacks return tokens, and running full generation to read one vector wastes the GPU. I added an extraction mode to the runtime itself, so the GPU spends nothing on tokens nobody needs. An engine built without a key-value cache routes to a raw TensorRT path that runs one forward pass per batch and returns the final hidden state of each sequence. A consumer has to pass a contract check before it may join the broker. design <figure class=\"dv-figure\" aria-label=\"Reading a representation by generation against one extraction pass\" <div class=\"dv-two\" <div <span class=\"eyebrow\" Generate to",
   "quote": "Validating vectors later cannot catch a well-formed vector for the wrong token.",
   "evidence": [
    "Hidden-state extraction at scale: a single-pass TensorRT mode returning 4,096-value vectors, about 203,000 extractions over 10.8M tokens of a 7-billion-parameter FP8 model.",
    "Fail-closed engineering: a warm-up probe that measures the engine's gather convention under both candidates and refuses to start on an ambiguous answer.",
    "High-throughput batch inference: buffers bound once at maximum shape and a fixed shape, address and copy order, averaging 25,800 tokens per second with a peak of 45,500."
   ],
   "technology_kind": "discipline"
  },
  {
   "url": "https://coreyjames.ai/technologies/hugging-face-hub/",
   "kind": "technology",
   "title": "Hugging Face Hub",
   "subtitle": "I published a 4-bit quantization of a 27-billion-parameter model with its card, provenance and measured trade-off.",
   "systems": [
    "activekv",
    "helix"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "400",
     "label": "text projection modules quantized to 4-bit"
    },
    {
     "value": "799",
     "label": "tensors left bit-identical to the source"
    },
    {
     "value": "433",
     "label": "files checked on the uploaded copy"
    }
   ],
   "lede": "A 4-bit checkpoint for one Intel card ActiveKV needed a 27-billion-parameter model on one 32 GB Intel Arc Pro GPU, and the hybrid recurrent-attention open-weight model I chose does not fit on it in BF16. I decided to quantize it myself on Intel's stock XPU vLLM build, measure the trade-off, and publish the result on the Hugging Face Hub so anyone with an Intel Arc Pro GPU could run it. The recipe is weight-only W4A16 on the text projection modules, with every other tensor bit-identical to the source. I pinned the source to a revision and checked every shard hash, and a per-module manifest lists what was quantized. I skipped calibration, so the checkpoint can be reproduced from the source",
   "quote": "I ran the release checks on the bytes that were uploaded, because a copy step can change them.",
   "evidence": [
    "LLM quantization (4-bit): a W4A16 build of a 27-billion-parameter model, 400 modules quantized and 799 tensors bit-identical, 55.6 GB to 20.6 GB, +36% throughput for +3.33% perplexity.",
    "Model release engineering: a published model card with method, tested environment and untested areas, and release checks run on the uploaded copy across 433 files.",
    "Human-approved model acquisition: agents plan a download and only a person at the local console approves it, with registration in a single transaction."
   ],
   "technology_kind": "platform"
  },
  {
   "url": "https://coreyjames.ai/technologies/hugging-face-text-embeddings-inference/",
   "kind": "technology",
   "title": "Hugging Face Text Embeddings Inference",
   "subtitle": "A local text-embedding inference server serves the embedding model to the memory service, replacing an earlier in-process binding.",
   "systems": [
    "fafohive"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "1,024",
     "label": "dimensions per embedding"
    },
    {
     "value": "~19,000",
     "label": "files in the monorepo's code index"
    },
    {
     "value": "~294,000",
     "label": "structure-aware chunks embedded from them"
    }
   ],
   "lede": "A model behind a service boundary The memory capability in FAFOHive searches code, reference documents and past decisions, and all of it depends on one multilingual embedding model. The first version ran that model in-process through a Python binding inside the Rust service. That put a Python runtime and a GPU model inside the Rust service, and every other service that needed embeddings would have loaded its own copy. I moved the model behind a service boundary, so it is loaded once and shared. Hugging Face's Text Embeddings Inference server runs that model on a local GPU, and the memory service calls it over HTTP through a provider abstraction. I kept the service's existing embedding interface fixed while the backend",
   "quote": "I make deliberate calls about where a model should live in a system and how a migration should land without breaking callers.",
   "evidence": [
    "Embedding inference serving: an in-process embedding model moved behind Hugging Face's inference server on a local GPU, with the embedding interface unchanged for every caller.",
    "Code search indexing: ~19,000 files embedded into ~294,000 structure-aware chunks at 1,024 dimensions.",
    "Mutual TLS client security: client certificates held only in memory and wiped on release, never written to disk, with capacity errors told apart from fatal ones."
   ],
   "technology_kind": "runtime"
  },
  {
   "url": "https://coreyjames.ai/technologies/hugging-face-transformers/",
   "kind": "technology",
   "title": "Hugging Face Transformers",
   "subtitle": "Hugging Face Transformers is the training path for my capabilities model: a full fine-tune of every parameter, finished in minutes, rebuilt whenever the catalog changes.",
   "systems": [
    "capabilities-model"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "~44%",
     "label": "of the base's parameters in feed-forward layers"
    },
    {
     "value": "28",
     "label": "layers, all with full attention"
    }
   ],
   "lede": "A model rebuilt on every catalog change Capabilities model holds an agent's tool catalog in the weights of a small model, and the catalog changes every week. If retraining took a day, the model would be stale on arrival. I chose a full fine-tune of every parameter of a small open-weight base model with Hugging Face Transformers, on a corpus generated from the tool registry. At this size the run takes minutes, so the model is rebuilt whenever the registry changes. I ran a full fine-tune over adapters, because at this size the cost that usually justifies adapters was absent and the full fine-tune removes a layer of indirection. design <figure class=\"dv-figure\" aria-label=\"Adapters against a full fine-tune: which parameters change\"",
   "quote": "I choose models by reading their architecture against the task, and I make training cheap enough to repeat on every catalog change.",
   "evidence": [
    "LLM fine-tuning: a full fine-tune of every parameter of a small base model with Hugging Face Transformers, rebuilt whenever the tool catalog changes.",
    "Model selection by architecture: candidates checked for feed-forward share (~44%), full attention on all 28 layers, remote code off and tokenizer fit, on a 360M, 0.6B and 1.7B capacity ladder.",
    "Training-to-inference handoff: safetensors loaded into a custom CUDA decoding engine behind an FP32 parity check."
   ],
   "technology_kind": "framework"
  },
  {
   "url": "https://coreyjames.ai/technologies/hybrid-retrieval/",
   "kind": "technology",
   "title": "Hybrid retrieval",
   "subtitle": "Dense embeddings fused with BM25 and reranked, with every constant found by sweep.",
   "systems": [
    "fafohive",
    "capabilities-model"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "~294,000",
     "label": "structure-aware chunks from about 19,000 files in one code index"
    },
    {
     "value": "129",
     "label": "configuration cells swept for the baseline's constants"
    },
    {
     "value": "5",
     "label": "embedding models in the bake-off before the sweep"
    }
   ],
   "lede": "Two kinds of question, three streams The memory service in FAFOHive serves agents that ask two kinds of question: an exact identifier such as a function name, and a description of behaviour in plain language. A dense vector search alone misses the first and lexical search alone misses the second, so I made code search and decision search hybrid. A query runs up to three streams at once (dense similarity on embeddings from a multilingual embedding model, weighted full-text search, and a metadata stream) and the ranked lists are fused with reciprocal-rank fusion. A classifier looks at each query first and sets how much each stream counts, because identifier queries and descriptive queries need different blends. design <figure class=\"dv-figure\" aria-label=\"The",
   "quote": "I swept the baseline's constants, because a baseline tuned less carefully than the model it judges proves nothing.",
   "evidence": [
    "Hybrid search and retrieval: dense, weighted full-text and metadata streams fused by reciprocal rank with cross-encoder rerank, over a code index of about 294,000 chunks.",
    "Information retrieval evaluation: a hybrid baseline swept across 129 configuration cells that tied the model at recall at 10 (0.977) and beat it on long, buried requests, 0.90 to 0.67.",
    "Search under load: bounded embedding and rerank endpoints, the reranker the first stage dropped under load with a flag, and a keyword-only mode with no embedding call."
   ],
   "technology_kind": "discipline"
  },
  {
   "url": "https://coreyjames.ai/technologies/idempotency-exactly-once-effects-and-crash-recovery/",
   "kind": "technology",
   "title": "Idempotency, exactly-once effects and crash recovery",
   "subtitle": "A restart never repeats a provider call, a broker restart never re-runs work the GPUs hold, and an agent's claimed completion is a claim.",
   "systems": [
    "agentos",
    "agent-swarm",
    "helix",
    "fafohive",
    "inference-fabric"
   ],
   "technologies": [],
   "stats": [],
   "lede": "The rule I apply in every system below is simple to state. design <blockquote class=\"dv-quote\" <p An outcome I cannot confirm gets reconciled by reading, never retried by sending again, and work is done when its result has been acknowledged.</p </blockquote I design for the crash window explicitly and decide, per system, whether a duplicate or a gap is the worse failure. No repeated payment, no second post FAFOHive lets agents use a payments provider, an email/CRM provider and social-publishing providers through a governed gateway. A repeated payment or a second marketing email is a real-world harm, so I made the gateway account for every call durably, and a restart does not repeat a provider call. The gateway's design is",
   "quote": "An outcome I cannot confirm gets reconciled by reading, never retried by sending again, and work is done when its result has been acknowledged.",
   "evidence": [
    "Exactly-once delivery and crash recovery: intent and budget committed before any provider call, and uncertain outcomes resolved by a read and never by a resend.",
    "Idempotency key design: keys bound to request inputs, so a replay returns the saved receipt and a replay with changed inputs is refused.",
    "Distributed systems correctness: a broker that counts work done only when acknowledged, and agent launches bound to an authorised claim so a replay returns the existing job."
   ],
   "technology_kind": "discipline"
  },
  {
   "url": "https://coreyjames.ai/technologies/identity-and-access-management-for-ai-agents/",
   "kind": "technology",
   "title": "Identity and access management for AI agents",
   "subtitle": "I worked out, from real tenant evidence, how an AI employee legitimately answers, calls and acts inside Microsoft 365, with per-employee tokens minted server-side and never handed to a model.",
   "systems": [
    "helix",
    "auth-and-access-plane"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "30 days",
     "label": "a pending client lives, for assistants that cache their client ID and never register again"
    }
   ],
   "lede": "One authorization server for every assistant Auth and access plane: I wanted commercial AI assistants, including Microsoft Copilot Studio, to reach my private tool estate on my terms. I was not willing to run a server per vendor or hand out a secret per connection, so I decided that one OAuth 2.0 authorization server would issue every token and that a person would approve every client. I built that server in Python. It issues RS256-signed JWTs and supports the authorization-code grant with PKCE, client credentials and refresh tokens, revocation, and the published key set and metadata documents that MCP clients read first. Assistants register themselves as temporary clients and wait for a person. design <figure class=\"dv-figure\" aria-label=\"An assistant's path to",
   "quote": "Microsoft remains the permission authority for the digital employee, and my layer grants nothing the tenant has not.",
   "evidence": [
    "OAuth 2.0 and identity architecture: one authorization server for every AI assistant, with PKCE, RS256 JWTs and a pending client lapsing after 30 days without a person's approval.",
    "Microsoft 365, Graph and Entra integration: digital employees acting as themselves with per-employee Graph tokens minted on the server and never placed in a model's context.",
    "Identity and least privilege for AI agents: Microsoft kept as the permission authority, typed refusals where no supported API exists, and one published key set trusted by three verifiers."
   ],
   "technology_kind": "discipline"
  },
  {
   "url": "https://coreyjames.ai/technologies/independent-verification-and-adversarial-review/",
   "kind": "technology",
   "title": "Independent verification and adversarial review",
   "subtitle": "Builders do not judge their own work. Quality assurance, a gatekeeper that accepts only delivered facts, and an adversarial reviewer on a different vendor's model are separate seats, and a FAIL stays a FAIL.",
   "systems": [
    "agentos",
    "auth-and-access-plane",
    "inference-fabric"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "5",
     "label": "judging seats, each with its own authority and none with the builder's"
    },
    {
     "value": "23",
     "label": "close items, each needing a current independent pass"
    },
    {
     "value": "14 days",
     "label": "a work order held open until every one of them had it"
    }
   ],
   "lede": "Separate seats for building and judging AgentOS: agent teams report success because they are built to finish tasks, and saying \"done\" finishes one. I decided the agent that builds a piece of work never judges it, and that the judging has to finish. AgentOS splits judgment into separate seats with separate authority, and the builders and the adversary run on models from different vendors so their blind spots do not overlap. design <figure class=\"dv-figure\" aria-label=\"The judging room: five seats with their authority around a floor, the builder outside it\" <div style=\"display: grid; grid-template-columns: minmax(0, 1fr) auto; gap: 1rem; align-items: center\" <div style=\"border-radius: 14px; background: var(--bg); border: 1px solid var(--rule); padding: 1rem; display: grid; grid-template-columns: repeat(auto-fit, minmax(96px, 1fr)); gap: 0.9rem\" <div",
   "quote": "I treat AI-produced work the way a quality organisation treats any work: the people who build it do not sign it off, and the sign-off has to end in a verdict.",
   "evidence": [
    "Separation of duties for AI work: builders never judge their own work; quality, a facts-only gatekeeper, a cross-vendor adversary, an envelope auditor and a closer hold separate authority.",
    "Evidence-gated acceptance: a work order held open 14 days until all 23 close items had a current independent pass.",
    "Converging quality loops for AI agents: findings frozen after the first broad pass, later rounds limited to fix claims and changed evidence, with round caps and an identical-failure guard.",
    "Adversarial code audit: read-only audits in parallel lanes grounded in code-graph tracing, one of which overturned an earlier sign-off on a vector shard manager."
   ],
   "technology_kind": "discipline"
  },
  {
   "url": "https://coreyjames.ai/technologies/intel-arc-gpus/",
   "kind": "technology",
   "title": "Intel Arc GPUs",
   "subtitle": "An Intel Arc Pro GPU is ActiveKV's home: a 27B model serving 128,000-token histories on one 32 GB card, kernel patches on a new architecture, and a published quantization built for it.",
   "systems": [
    "activekv",
    "capabilities-model",
    "helix"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "4",
     "label": "patches to Intel's own kernel sources, each with identical outputs"
    },
    {
     "value": "~36%",
     "label": "more sustained throughput, all-4-bit against a mixed 4-bit and 8-bit control"
    },
    {
     "value": "3.33%",
     "label": "higher perplexity paid for that throughput, eight-document diagnostic set"
    }
   ],
   "lede": "Long contexts on one 32 GB card ActiveKV: I wanted a 27B hybrid model to serve long contexts on one 32 GB card. On a 32 GB Intel Arc Pro GPU the key-value cache was the wall, and I chose to make that card the target and fix the stack where it fell short. ActiveKV keeps attention history in pinned host memory and gives the card a bounded working set, so a 4-bit-weight build of a 27-billion-parameter hybrid recurrent-attention open-weight model serves histories from 32K tokens upward on a single card. On the release build, an 8,000-token single request against stock vLLM on the same card: design <figure class=\"dv-figure\" aria-label=\"ActiveKV release build against stock vLLM on one Intel Arc Pro",
   "quote": "Every kernel patch had to produce identical outputs before I took any speed from it.",
   "evidence": [
    "Intel GPU and SYCL/oneAPI engineering: Intel kernel sources patched on Xe2 with identical outputs, cold 32K-token prefill cut from 21.54 s to 17.23 s and recurrent prefill from 53.8 to 27.4 ms per chunk.",
    "LLM quantization (4-bit): a calibration-free W4A16 build taking a 27B hybrid model from 55.6 GB to 20.6 GB for one 32 GB card, about 36% more throughput for 3.33% higher perplexity.",
    "GPU inference optimisation: an 8,000-token request at 3.68 s to first token and 43.3 ms per token, against 4.71 s and 45.3 ms for stock vLLM on the same Intel Arc Pro card.",
    "Profiling methodology: a trace conclusion about copy and compute overlap retracted after a controlled experiment showed the timing events themselves serialised the copy engine."
   ],
   "technology_kind": "hardware"
  },
  {
   "url": "https://coreyjames.ai/technologies/intel-oneapi/",
   "kind": "technology",
   "title": "Intel oneAPI",
   "subtitle": "Intel's oneAPI stack is what ActiveKV's native engine and its kernel patches are built against, inside the vendor's own toolchain for ABI match.",
   "systems": [
    "activekv"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "192",
     "label": "Unified-Runtime entry points covered by the generated preload shim"
    },
    {
     "value": "~18",
     "label": "engine files calling Level Zero directly"
    },
    {
     "value": "3.12",
     "label": "the oneDNN version the patch series targets"
    }
   ],
   "lede": "ActiveKV's native engine and every kernel patch sit on Intel's oneAPI stack: SYCL and DPC++, Level Zero, the Unified Runtime, oneDNN, and the PTI and unitrace tracing tools. I saw a choice between treating that stack as a black box and working at whatever level a problem lived at. I chose the second, and the work ran at three levels. Kernel library patches The first level is the kernel libraries. Patches are built against the vendor's own sources inside the vendor's image, with Intel's toolchain, so the ABI matches what the serving engine loads and a whole class of mismatch disappears. The oneDNN work is a series of patches. One is a kernel-catalogue entry for Xe2 large-N GEMM shapes. design",
   "quote": "I kept a rewrite that produced exact arithmetic with no whole-workload gain, because exactness is a property I want in the product.",
   "evidence": [
    "Intel GPU and SYCL/oneAPI engineering: oneDNN 3.12 patches built in the vendor's image, a Xe2 GEMM catalogue entry cutting cold 32K-token prefill from 21.54 s to 17.23 s with identical outputs.",
    "Low-level GPU runtime programming: Level Zero and unified shared memory for pinned host pools, staging and fences, called from ~18 engine files.",
    "GPU profiling and tracing: a generated preload shim over 192 Unified-Runtime entry points tying host calls to device intervals."
   ],
   "technology_kind": "runtime"
  },
  {
   "url": "https://coreyjames.ai/technologies/javascript/",
   "kind": "technology",
   "title": "JavaScript",
   "subtitle": "Relays, meeting-stage apps, extension scripts and the OAuth consent surfaces are JavaScript where the platform demands it.",
   "systems": [
    "helix",
    "fafohive",
    "auth-and-access-plane"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "≈300",
     "label": "lines in the edge proxy"
    },
    {
     "value": "≈11,000",
     "label": "lines of Mattermost webapp plugin code"
    },
    {
     "value": "95",
     "label": "webapp tests on the council interface"
    },
    {
     "value": "20",
     "label": "test cases on the meeting-stage relay"
    }
   ],
   "lede": "An edge proxy as the only public surface Microsoft Copilot Studio needed to call tools on my private MCP server in the Auth and access plane, and I did not want that server to accept a single public connection. I put a small edge proxy in front of it, written in JavaScript for an edge Workers runtime, and it is the only public surface. The connector sends unauthenticated discovery probes, and the proxy answers those without credentials. On every real call it checks a tenant-pinned Microsoft Entra JWT. The edge runtime has no Node crypto, so the RS256 check uses WebCrypto against signing keys cached in the edge key-value store, and a call never waits on a key fetch. design",
   "quote": "I pick the language the platform dictates and hold it to the same security bar as the Rust services behind it.",
   "evidence": [
    "Edge security in JavaScript: a proxy of about 300 lines as the only public surface of a private MCP server, checking Entra JWTs with WebCrypto and rotating keys without downtime.",
    "Browser extension development: a Manifest V3 extension that acts in my own session through same-origin requests and never exports cookies or tokens.",
    "Chat platform plugins: about 11,000 lines of Mattermost webapp plugin code with 95 tests, keeping the chat server stock.",
    "Webhook security: a timestamped HMAC over the exact bytes inside a replay window, with duplicates dropped and two secrets accepted during rotation."
   ],
   "technology_kind": "language"
  },
  {
   "url": "https://coreyjames.ai/technologies/json-rpc/",
   "kind": "technology",
   "title": "JSON-RPC",
   "subtitle": "JSON-RPC is the transport under the Model Context Protocol surfaces I build and consume.",
   "systems": [
    "agent-swarm",
    "fafohive",
    "fafo-core"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "22",
     "label": "custom error codes a client can branch on"
    },
    {
     "value": "3",
     "label": "MCP servers mapped by the read-only explorer"
    }
   ],
   "lede": "Routing generated from YAML In FAFO Core and Function Forge I expected the number of tools to grow faster than anyone could hand-wire gateway routes. So I made JSON-RPC 2.0, the envelope of the Model Context Protocol, something the gateway serves from generated code. The gateway is an Axum server that speaks MCP over HTTP with the .well-known MCP configuration, protected-resource metadata and session headers. At build time a generator turns a YAML trio per tool into handlers and routing, so a new function becomes callable without anyone editing gateway code, and the gateway and its catalog cannot drift apart. design <figure class=\"dv-figure\" aria-label=\"From a YAML trio to a callable tool\" <div class=\"dv-two\" <div <span class=\"eyebrow\" One tool, three files</span",
   "quote": "I treat the wire envelope as plumbing that should be generated, typed and boring.",
   "evidence": [
    "MCP server design: JSON-RPC routing generated from YAML at build time, with 22 custom error codes a client can branch on.",
    "Resilient transports: a streaming session that broke on container restarts replaced by stateless JSON-RPC over HTTPS.",
    "Agent-to-agent messaging: JSON-RPC envelopes aligned with the Agent Client Protocol over Redis streams, including a call that starts an agent on another host."
   ],
   "technology_kind": "protocol"
  },
  {
   "url": "https://coreyjames.ai/technologies/json-schema/",
   "kind": "technology",
   "title": "JSON Schema",
   "subtitle": "Every work-order contract, tool definition and generated function surface in my estate is a JSON Schema, and schemas compile into dispatch at build time.",
   "systems": [
    "agentos",
    "agent-swarm",
    "fafo-core"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "33",
     "label": "schema contracts governing AgentOS handoffs"
    },
    {
     "value": "12",
     "label": "semantic rules checking each API reference"
    },
    {
     "value": "≈2,000",
     "label": "lines of Rust in the harness validator"
    }
   ],
   "lede": "Contracts at every handoff Long agent runs drift when the handoffs between agents are prose, because each agent reinterprets what the last one meant. In AgentOS I made every handoff a contract and chose JSON Schema as the contract language. The .schema.json contracts cover work-order sources, authoring plans, work packages and the structured output of model checkers. Every seam is checked on both sides, so a malformed artefact cannot pass through a component that trusts its upstream. The PostgreSQL work graph and its schemas are the truth; Markdown views are generated from them, and edits to those views are discarded. design <figure class=\"dv-figure\" aria-label=\"One handoff, checked on both sides\" <div style=\"display: flex; flex-direction: column; gap: 10px; margin-top: 0.8rem\" <div style=\"display:",
   "quote": "I put the checks where a bad artefact would otherwise pass unnoticed.",
   "evidence": [
    "Contract-driven agent handoffs: 33 JSON Schema contracts in AgentOS, each seam checked by both producer and consumer.",
    "Structured output for LLMs: flat, closed verdict schemas so model checkers return data instead of drifting prose.",
    "Evidence-gated API integration: a field enters an API manifest only once a successful call to the real API returned it, checked by 12 semantic rules.",
    "Input validation at scale: about 2,000 lines of Rust validating every tool call as the first step of the harness."
   ],
   "technology_kind": "protocol"
  },
  {
   "url": "https://coreyjames.ai/technologies/json-web-token-jwt/",
   "kind": "technology",
   "title": "JSON Web Token (JWT)",
   "subtitle": "Scoped JWTs for agent seats, employee-scoped tokens for Microsoft identities, bearer introspection that fails closed. Identity in my systems is derived from the token, never from tool input.",
   "systems": [
    "agentos",
    "agent-swarm",
    "fafohive",
    "fafo-core",
    "auth-and-access-plane"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "1 hour",
     "label": "each issuer's key set is cached at the gateway"
    },
    {
     "value": "3",
     "label": "runtimes trusting the same kind of anchor"
    }
   ],
   "lede": "Tokens checked without calling the issuer In the Auth and access plane I had assistants from several vendors calling one private tool estate, and I wanted every call checked without a round trip to the issuer. I made JWTs the token format and published keys the trust anchor. My Python OAuth server issues RS256-signed access tokens carrying issuer, audience, expiry and coarse MCP scope claims, publishes its key set and persists its signing key, so assistants holding long-lived refresh tokens keep working through a restart. The Rust tool gateway validates against published key sets from more than one issuer, which lets it accept tokens from my server and from Microsoft's platform. For Microsoft Copilot Studio, an edge proxy checks tenant-pinned",
   "quote": "A caller cannot name itself in the arguments.",
   "evidence": [
    "OAuth and identity architecture: RS256 tokens issued in Python and checked offline in Rust and at the edge against published key sets cached for 1 hour.",
    "Delegation security for AI agents: every agent-to-agent message a signed JWT over a canonical hash, with depth limits and cycle detection.",
    "Least privilege for AI agents: identity derived from the token on every surface, never from tool arguments, and a sub-agent's identity ends with its parent's."
   ],
   "technology_kind": "protocol"
  },
  {
   "url": "https://coreyjames.ai/technologies/kv-cache-engineering/",
   "kind": "technology",
   "title": "KV-cache engineering",
   "subtitle": "The key-value cache is the largest thing on the card after the weights. I moved it to the host in ActiveKV, kept it hot in the Inference Fabric's broker, and in both cases measured the bus.",
   "systems": [
    "activekv",
    "inference-fabric",
    "capabilities-model"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "3.3%",
     "label": "worst error of the bus latency model against measurement, 32K to 262K tokens"
    },
    {
     "value": "262K",
     "label": "token context on one card, at a 22 GiB device peak"
    },
    {
     "value": "−6.8%",
     "label": "throughput from KV offload on the NVIDIA serving path"
    }
   ],
   "lede": "Costing the bus before changing anything ActiveKV: stock serving keeps a request's whole key-value cache on the GPU, so a 32 GB card caps how much context it can hold. I made pinned host memory the owner of the cache and gave the GPU a bounded working set. The exact path re-reads every byte of history for every generated token, so I wrote the cost down as a latency model before changing anything. design <figure class=\"dv-figure\" aria-label=\"The bus arithmetic: sixteen attention layers of history per token, re-read for every generated token\" <span class=\"eyebrow\" The model's 64 layers · 16 hold attention history</span <div style=\"display: grid; grid-template-columns: repeat(32, minmax(0, 1fr)); gap: 2px; margin-top: 0.7rem\" aria-hidden=\"true\" <span style=\"height: 16px; border-radius: 3px; background:",
   "quote": "I count bytes before I optimise.",
   "evidence": [
    "KV-cache offload for LLM inference: pinned host memory as owner of the cache and a leased, bounded GPU working set, with whole-layer staging bit-identical to fully resident attention.",
    "Performance modelling: a bus latency model that predicted measured inter-token latency within 3.3% from 32K to 262K tokens, with a 262K-token context at a 22 GiB device peak.",
    "Attention kernel engineering: exact log-sum-exp merging of tiled attention over exact and 8-bit pages, with a log-sum-exp output patched into the vendor's paged-decode kernel.",
    "Latency engineering under concurrency: a hybrid tier at 190 ms per token against 335 ms exact at 128K, and about 8 GB of freed memory spent to cut latency from 274 ms to 141 ms."
   ],
   "technology_kind": "discipline"
  },
  {
   "url": "https://coreyjames.ai/technologies/large-scale-gpu-data-pipelines/",
   "kind": "technology",
   "title": "Large-scale GPU data pipelines",
   "subtitle": "A generation pipeline that populated tens of millions of dataset items on two consumer GPUs, with persistent item identities, lease-based claiming and prompts baked at build time for cache reuse.",
   "systems": [
    "fafo-core",
    "inference-fabric",
    "capabilities-model"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "876K",
     "label": "probes submitted in one captured window"
    },
    {
     "value": "131 M",
     "label": "tokens pending in that window"
    },
    {
     "value": "156/s",
     "label": "probes per second, with zero retries"
    },
    {
     "value": "~203K",
     "label": "hidden-state extractions over 10.8 M tokens, 7B dense model in FP8"
    }
   ],
   "lede": "Generating tens of millions of traceable items FAFO Core and Function Forge: my distillation research needed tens of millions of model-generated dataset items. Each one had to trace back to the knowledge it came from, and they had to be produced fast enough to keep two consumer GPUs saturated. I treated that as an industrial data pipeline, and I let the workload itself decide what the substrate needed. The probe generator is a Rust function on the FAFO Core substrate. It reads a unified work view over three source types, assembles class-specific prompts, submits them to the GPU broker, and stores each result as a token-ID array with provenance. It runs in service mode with queue-depth triggers. design <figure class=\"dv-figure\"",
   "quote": "A research result that cannot be reproduced is worth little.",
   "evidence": [
    "High-throughput batch inference: tens of millions of traceable dataset items on two NVIDIA Blackwell GPUs, 876K probes and 131 M tokens in one window at 156/s with zero retries.",
    "Prefix-cache engineering: prompts tokenized at build time and baked into the binary so every class shares a byte-identical prefix the inference engine reuses from cache.",
    "Reproducible ML data capture: hidden-state mining runs content-addressed and safe to resubmit, about 203K extractions over 10.8 M tokens from a 7B dense model in FP8."
   ],
   "technology_kind": "discipline"
  },
  {
   "url": "https://coreyjames.ai/technologies/large-scale-refactoring-with-parity-proof/",
   "kind": "technology",
   "title": "Large-scale refactoring with parity proof",
   "subtitle": "Rewrite a system, prove it is the same system. My governance platform's own refactors carry parity proofs, and the largest example is a GPU runtime ported to C++ without changing a token.",
   "systems": [
    "agentos",
    "activekv"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "21",
     "label": "domain modules the two oversized files became"
    },
    {
     "value": "430+",
     "label": "tests moved alongside the code they cover"
    },
    {
     "value": "63 → 1",
     "label": "shell hooks ported to one Rust binary"
    },
    {
     "value": "13 of 13",
     "label": "exact cells bit for bit at the C++ port, 12 of 12 compressed"
    }
   ],
   "lede": "Splitting two oversized files into modules AgentOS: the AgentOS store and admin CLI had grown into two very large Rust files, and I had them split into domain modules. design <figure class=\"dv-figure\" aria-label=\"Two oversized Rust files split into domain modules, with the entry files reduced to a few dozen lines\" <span class=\"eyebrow\" Lines in the entry files</span <div class=\"dv-bars\" <span Store, before</span <span class=\"bar\" style=\"width: 95%\" </span <span class=\"v\" 40,300</span <span Admin CLI, before</span <span class=\"bar\" style=\"width: 100%\" </span <span class=\"v\" 42,500</span <span Library root, after</span <span <span class=\"bar on\" style=\"width: 1%\" </span </span <span class=\"v on\" 20</span <span Admin main, after</span <span <span class=\"bar on\" style=\"width: 1%\" </span </span <span class=\"v on\" 67</span </div <figcaption Every agent that touched",
   "quote": "I decided the split was finished only when someone who had not done it could show it was the same system.",
   "evidence": [
    "C++ and native ports with parity proof: a GPU serving runtime ported from Python to native C++ without changing a token, 13 of 13 exact cells and 12 of 12 compressed cells bit for bit.",
    "Large-scale refactoring: two Rust files of about 40,300 and 42,500 lines split into 21 domain modules, with 430+ tests moved alongside the code they cover.",
    "Parity proof by an independent witness: a seat that did not do the work took test baselines, built its own release binaries and compared exported symbols before and after.",
    "Rust systems engineering: 63 shell hooks ported to one Rust binary, tested against fake hook contexts and published byte for byte."
   ],
   "technology_kind": "discipline"
  },
  {
   "url": "https://coreyjames.ai/technologies/ld-preload-symbol-interposition/",
   "kind": "technology",
   "title": "LD_PRELOAD symbol interposition",
   "subtitle": "Symbol interposition let me intercept runtime calls directly when the vendor's tracing path was itself distorting measurements.",
   "systems": [
    "activekv"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "192",
     "label": "Unified-Runtime entry points wrapped, generated from the runtime's own interface"
    },
    {
     "value": "1",
     "label": "instrumented capture at a time through the vendor path; concurrent through the shim"
    },
    {
     "value": "0",
     "label": "per-call state kept by the shim: forward, write one flat entry, return"
    }
   ],
   "lede": "LD PRELOAD symbol interposition Finding the leak before replacing anything ActiveKV: the step-profiling suite follows each generated token from the scheduler through every device kernel and copy to the client. Its most detailed level associates Intel Unified-Runtime calls with device intervals and host waits. That capture first went through the vendor's tracing layer, and every capture grew the server process for its whole lifetime. I wanted to know where the memory went before replacing anything. I ran controlled micro-loop experiments that set my collector against a subscriber with no callback attached. The subscriber with no callback still kept memory on every driver call. design <figure class=\"dv-figure\" aria-label=\"Server memory over a capture: rising with vendor tracing, with or without a callback,",
   "quote": "The instrument must not become the result.",
   "evidence": [
    "Dynamic linker interposition (LD_PRELOAD): an observer shim generated for all 192 Intel Unified Runtime entry points from the runtime's own interface, forwarding each call and writing one flat entry.",
    "GPU profiling and tracing: a leak located in the vendor's tracing path by a no-callback control before anything was replaced, so instrumented captures could run concurrently.",
    "Trace processing at scale: a Rust parser with parallel chunks and trace caches turning tens of gigabytes of capture into host-call to device-work associations with stated clock uncertainty."
   ],
   "technology_kind": "discipline"
  },
  {
   "url": "https://coreyjames.ai/technologies/lease-based-work-claiming/",
   "kind": "technology",
   "title": "Lease-based work claiming",
   "subtitle": "Parallel workers claim work by lease, designed against the dead-tuple behaviour of PostgreSQL's concurrency model, so two workers never process the same item and nothing is lost on a crash.",
   "systems": [
    "fafo-core"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "0.7–1 M",
     "label": "items in flight at once over a two-hour window"
    },
    {
     "value": "3",
     "label": "ways the conductor slices a job; leased claiming is one"
    },
    {
     "value": "2",
     "label": "NVIDIA Blackwell GPUs fed by the claimed work"
    }
   ],
   "lede": "Claiming designed against dead tuples FAFO Core and Function Forge: my probe-generation workload had parallel workers pulling rows of work from PostgreSQL, and two of them collided on the same item. I needed claiming that holds up under tens of millions of items and survives a worker dying mid-batch. I did not want to pay for it with database churn. The obvious pattern, updating a row to claim it and updating it again to release it, leaves dead tuples behind on every cycle, and at that scale the vacuum load becomes its own problem. design <figure class=\"dv-figure\" aria-label=\"The obvious claim-and-release pattern leaves dead row versions behind on every cycle\" <span class=\"eyebrow\" One work row under the obvious pattern · update",
   "quote": "I design concurrency against the real costs of the database underneath, and I put the hard part in a framework so every function inherits it.",
   "evidence": [
    "Distributed job orchestration: time-bounded, renewable leases on work items, so a crash neither loses an item nor lets two workers process it, built into the framework once.",
    "PostgreSQL performance tuning: work claiming designed against the dead-tuple cost of claiming and releasing a row by update under heavy concurrency.",
    "High-throughput batch inference: leased claiming that carried tens of millions of work items across 2 NVIDIA Blackwell GPUs, with 0.7 to 1 M in flight at once."
   ],
   "technology_kind": "discipline"
  },
  {
   "url": "https://coreyjames.ai/technologies/link-time-plugin-registration/",
   "kind": "technology",
   "title": "Link-time plugin registration",
   "subtitle": "A generated function is registered at link time so that it is fully wired or the build fails. There is no half-registered state.",
   "systems": [
    "fafo-core"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "14",
     "label": "function crates on the substrate"
    },
    {
     "value": "7",
     "label": "of them produced by the generator"
    },
    {
     "value": "2",
     "label": "registrations in every slice entry"
    },
    {
     "value": "3",
     "label": "actions per tool in the gateway"
    }
   ],
   "lede": "Registration as a property of the build FAFO Core and Function Forge: a tool can be half-registered. I had seen hand-written registration routines drift that way. When agents started generating functions, I decided registration would be a property of the build, so discovery happens at link time and nothing can drift between what is built and what is registered. design <figure class=\"dv-figure\" aria-label=\"Half-registered states under hand-written registration, against link-time registration\" <div class=\"dv-two\" <div <span class=\"eyebrow\" Hand-written registration</span <div style=\"position: relative; display: grid; grid-template-columns: repeat(3, minmax(0, 1fr)); gap: 4px 6px; margin-top: 0.8rem\" <span aria-hidden=\"true\" style=\"position: absolute; left: calc(50% / 3); right: calc(50% / 3); top: 14px; height: 3px; border-radius: 2px; background: var(--rule)\" </span <div style=\"display: flex; justify-content: center; align-items: center; height:",
   "quote": "It puts a human gate at the moment a tool becomes callable, and I wanted the gate there.",
   "evidence": [
    "Rust systems engineering: link-time plugin registration through distributed slices, so each of 14 function crates is fully wired or the build fails.",
    "Code generation and metaprogramming: 7 of the 14 function crates produced by a generator, with a generated composition root and tool list that nobody edits by hand.",
    "Human-in-the-loop governance for AI-generated code: a rebuild and restart I authorise as the gate before any generated tool reaches agents."
   ],
   "technology_kind": "discipline"
  },
  {
   "url": "https://coreyjames.ai/technologies/linux-security-primitives/",
   "kind": "technology",
   "title": "Linux security primitives",
   "subtitle": "Container limits, path safety, shell allow-lists, UID pinning and egress control are the floor under my agent runtime, not an afterthought.",
   "systems": [
    "agentos",
    "agent-swarm"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "0",
     "label": "commits by the coding agent's worker to the main repository"
    }
   ],
   "lede": "A sandbox declared once per persona Agent Swarm: every new agent tends to arrive with its own idea of what it may touch. I wanted the isolation floor declared once, as data, and inherited by every agent class. Each persona in the catalog carries a sandbox section, so a new agent class gets the floor without new code. design <figure class=\"dv-figure\" aria-label=\"The sandbox a persona declares: the container, its mounts and its shell rules\" <div class=\"dv-two\" <div <span class=\"eyebrow\" Declared in the persona</span <div style=\"margin-top: 0.8rem; border: 2px solid var(--navy); border-radius: 12px; padding: 10px; display: grid; gap: 6px\" <span class=\"lbl\" style=\"font-size: 0.74rem\" Container · resource limits from the persona</span <div style=\"height: 34px; border-radius: 8px; background: var(--tone); display: flex; align-items: center;",
   "quote": "On a single host the kernel already knows who is calling, so I check peer credentials on local sockets and keep shared secrets off that path.",
   "evidence": [
    "Sandboxing and container hardening: per-persona sandboxes declaring container limits, workspace type and shell allow and deny patterns, inherited by every agent class.",
    "Linux security primitives: cross-user message delivery through a socket-activated Unix socket checked with kernel peer credentials, with no shared secrets on that path.",
    "Least privilege for AI agents: a coding agent that pushed from a throwaway container under a shell allow-list and made 0 commits to the main repository."
   ],
   "technology_kind": "discipline"
  },
  {
   "url": "https://coreyjames.ai/technologies/llm-fine-tuning/",
   "kind": "technology",
   "title": "LLM fine-tuning",
   "subtitle": "A full-parameter fine-tune of a 0.6B model on registry-generated data, finished in minutes, measured on a frozen set against a baseline that tied it.",
   "systems": [
    "capabilities-model"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "17.6 GiB",
     "label": "peak memory for the recipe on one GPU"
    },
    {
     "value": "12",
     "label": "cells in the ladder across 0.36B, 0.6B and 1.7B models"
    },
    {
     "value": "4",
     "label": "model families on the authoring panel"
    },
    {
     "value": "2–14 min",
     "label": "for one training run"
    }
   ],
   "lede": "A model rebuilt the way an index is Capabilities model: my agents were carrying the whole tool schema on every turn. I wanted a small model that holds the tool catalog in its weights and answers one discovery call. Tools change weekly, so retraining had to take minutes. I chose a full-parameter fine-tune of a 0.6-billion-parameter open-weight base model over adapters, because at 0.6B a full fine-tune is fast enough that the usual case for adapters disappears. Because training takes minutes, I rebuild the model the way I rebuild an index. design <figure class=\"dv-figure\" aria-label=\"What a catalog change goes through\" <div style=\"position: relative; display: grid; grid-template-columns: repeat(5, minmax(0, 1fr)); gap: 4px 6px; margin-top: 0.8rem\" <span aria-hidden=\"true\" style=\"position: absolute; left: calc(50%",
   "quote": "The strongest classical baseline tied the model, and I report the tie.",
   "evidence": [
    "LLM fine-tuning: full-parameter fine-tunes of a 0.6B model on one GPU in 2 to 14 minutes at a 17.6 GiB peak, so the tool-catalog model is rebuilt like an index.",
    "Synthetic training data generation: an authoring panel of 4 model families with a gate that polices its own authors and quarantined 336 templated entries.",
    "ML evaluation methodology: a frozen corpus of 2,909 examples with no overlap with a 469-query evaluation set, where recall at 5 of 0.955 tied a classical baseline at 0.949."
   ],
   "technology_kind": "discipline"
  },
  {
   "url": "https://coreyjames.ai/technologies/lua/",
   "kind": "technology",
   "title": "Lua",
   "subtitle": "Lua scripts make the Redis control plane's job promotion atomic and keep the broker's hot-path bookkeeping on the server.",
   "systems": [
    "fafo-core",
    "inference-fabric",
    "postgresql-fabric"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "16",
     "label": "scripts in the server-side library"
    },
    {
     "value": "≈4,000",
     "label": "lines of Lua, loaded by hash"
    },
    {
     "value": "3",
     "label": "Redis instances, one per role"
    }
   ],
   "lede": "Job state that cannot be half-updated The FAFO Core and Function Forge control plane keeps job state in Redis, and many workers change that state at once. A Redis pipeline batches commands without making them atomic, and a crash or a competing worker between two commands leaves a job half-updated. I moved every multi-step state change onto the server as a Lua script. Job promotion is one script: it moves a job from pending to processing and writes the job's worker count, batch size and batch mode in the same step, so no worker ever sees a half-promoted job. design <figure class=\"dv-figure\" aria-label=\"Job promotion as a client sequence and as one script\" <div style=\"display: flex; flex-direction: column; gap: 10px; margin-top:",
   "quote": "I find the places where distributed state can tear and close them at the server.",
   "evidence": [
    "Redis Lua scripting: 16 server-side scripts of about 4,000 lines making multi-step job state changes atomic.",
    "Distributed systems correctness: scripts that return the state they produced, removing read-after-write races from every caller.",
    "Workload isolation: 3 Redis instances split by role so a write backlog cannot starve job control."
   ],
   "technology_kind": "language"
  },
  {
   "url": "https://coreyjames.ai/technologies/mattermost/",
   "kind": "technology",
   "title": "Mattermost",
   "subtitle": "An unmodified open-source team chat server hosts my multi-model collaboration shell, with bot seats for several vendors and a council mode that deliberates rather than fans out.",
   "systems": [
    "helix"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "8",
     "label": "frontier seats across three model families"
    },
    {
     "value": "100",
     "label": "posts, or 192 KiB, of room history read per turn"
    },
    {
     "value": "66 KB",
     "label": "prompt one terminal tool dropped without a word"
    }
   ],
   "lede": "A stock chat server as the shell I work with several frontier models and a local one at the same time, and separate chat windows kept losing the thread. For Helix I wanted one room where people and models work together, each model a named participant, so I built it on Mattermost Team Edition, run unmodified. Helix is the product and Mattermost is the shell, and every fact has one owner, which keeps the two from becoming competing control planes. design <figure class=\"dv-figure\" aria-label=\"One owner for every fact\" <div style=\"display: flex; align-items: flex-start; justify-content: center; gap: 6px; flex-wrap: wrap; margin-top: 0.8rem\" <div style=\"display: flex; flex-direction: column; align-items: center; gap: 4px; text-align: center; min-width: 72px; max-width: 130px; margin: 0 6px\" <svg",
   "quote": "The room itself became the council.",
   "evidence": [
    "Multi-agent collaboration systems: an unmodified Mattermost server hosting people and 8 frontier model seats, extended only through plugins, bots and a bridge.",
    "Exactly-once delivery and crash recovery: a Rust bridge that repairs missing posts after a restart and never runs a model turn twice.",
    "Consensus protocols for AI agents: a council that runs every seat at once in the room and closes only on agreement with the exact current outcome."
   ],
   "technology_kind": "platform"
  },
  {
   "url": "https://coreyjames.ai/technologies/mcp-tool-design/",
   "kind": "technology",
   "title": "MCP tool design",
   "subtitle": "Tools shaped as jobs, cost stated on every call, every write read back, every create with a delete: the written standard every MCP tool in my estate must meet.",
   "systems": [
    "fafohive",
    "helix",
    "capabilities-model"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "~42,000",
     "label": "tokens of tool schema an agent had carried every turn"
    },
    {
     "value": "24",
     "label": "meeting tools, each with a minimal exact schema"
    },
    {
     "value": "520",
     "label": "characters in the discovery tool's description, held there by a test"
    }
   ],
   "lede": "Tools shaped like jobs, not endpoints FAFOHive: when I added in-house social integrations to the tool hub, the fast path was to generate one tool per vendor endpoint. I took it once. The X module's first build compiled its tools straight from the vendor's OpenAPI specification. They were cheap to make, expensive to call and easy for an agent to misuse. I withdrew that surface and replaced it with tools shaped like the jobs agents actually do, trading generated breadth for designed workflow tools with costs and guards. design <figure class=\"dv-figure\" aria-label=\"Job tools on top, the generated catalog underneath as private plumbing\" <span class=\"eyebrow\" What agents see · job tools with costs and guards</span <div aria-hidden=\"true\" style=\"display: grid; grid-template-columns: repeat(6,",
   "quote": "An agent cannot budget what it cannot see, so every call states its cost.",
   "evidence": [
    "MCP server design: a written standard for every tool, shaped as a job, with a stated cost formula, verbatim errors, read-back writes and a delete for every create.",
    "Tool surface design for agents: ~42,000 tokens of per-turn tool schema replaced by one discovery tool whose 520-character description is held by a test.",
    "Lifecycle testing of agent tools: every kind of post and media created, checked and deleted through agent tools alone, finding 3 platform-semantics defects.",
    "Agent-safe API integration: 24 meeting tools with minimal exact schemas and typed refusals where Microsoft offers no supported action."
   ],
   "technology_kind": "discipline"
  },
  {
   "url": "https://coreyjames.ai/technologies/messagepack/",
   "kind": "technology",
   "title": "MessagePack",
   "subtitle": "Compact binary serialisation on the agent runtime's message bus and the broker's internal entries.",
   "systems": [
    "agent-swarm",
    "fafo-core",
    "inference-fabric",
    "postgresql-fabric"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "16",
     "label": "fixed fields in every write message"
    },
    {
     "value": "3",
     "label": "encodings, each chosen for its path"
    }
   ],
   "lede": "One write path, no database connections In FAFO Core and Function Forge I wanted hundreds of workers to write results without any of them holding a database connection, so functions never write to PostgreSQL directly. A producer client encodes each write as a flat MessagePack message and appends it fire-and-forget to a Redis stream. A single governed write service then owns the write, one path from many producers into the database. I chose MessagePack because producers needed a compact, self-describing encoding that the writer could route without decoding the whole message. On a hot path I prefer a flat, fixed field set: the writer reads where a message goes with no database query and no schema lookup. design <figure class=\"dv-figure\"",
   "quote": "A wire contract that matters has to be checked where it is consumed.",
   "evidence": [
    "Write-path design: producers append flat MessagePack messages with 16 fixed fields to a Redis stream, so no worker holds a database connection.",
    "Data contract enforcement: a convention-only contract left one producer's messages stranded, so contracts are now checked where they are consumed.",
    "Serialisation design: MessagePack, canonical CBOR and bincode each chosen for what its path needs."
   ],
   "technology_kind": "protocol"
  },
  {
   "url": "https://coreyjames.ai/technologies/meta-graph-api/",
   "kind": "technology",
   "title": "Meta Graph API",
   "subtitle": "An in-house integration with Meta's Graph API, with usage telemetry, a ledger of everything the app created, and signature-checked webhooks.",
   "systems": [
    "fafohive"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "24",
     "label": "agent tools on the Graph API"
    },
    {
     "value": "24 hours",
     "label": "Messenger response window the inbox works inside"
    }
   ],
   "lede": "A module built on the Graph API In FAFOHive, agents managing a business Page needed to publish every kind of media, answer comments and messages inside Meta's rules, read insights, and undo anything they created. The social-publishing provider I had covered posting and little else, so I built an in-house module directly on Meta's Graph API and held it to my tool standard. design <figure class=\"dv-figure\" aria-label=\"What the tools cover\" <div style=\"display: flex; flex-wrap: wrap; gap: 8px; justify-content: center; margin-top: 0.8rem\" <div style=\"display: flex; flex-direction: column; align-items: center; gap: 4px; width: 82px\" <div style=\"width: 70px; height: 86px; border-radius: 8px; border: 1.5px solid var(--ink-3); padding: 6px; box-sizing: border-box; display: flex; flex-direction: column; gap: 4px\" <span style=\"height: 5px; width: 90%; border-radius: 3px;",
   "quote": "I learn a platform's real behaviour by exercising it end to end.",
   "evidence": [
    "Social platform API integration: 24 agent tools built on Meta's Graph API, covering posts of every media kind, comments, the inbox and insights.",
    "Safe destructive operations for agents: a ledger that can veto a delete but never authorise one, with Graph's own record as the authority.",
    "Acceptance testing for agent tools: a full post lifecycle created and deleted through the tools with zero HTTP requests outside a tool body."
   ],
   "technology_kind": "platform"
  },
  {
   "url": "https://coreyjames.ai/technologies/microsoft-agent-365/",
   "kind": "technology",
   "title": "Microsoft Agent 365",
   "subtitle": "I provisioned a governed digital employee under Microsoft's Agent 365, and built the MCP server through which any model acts in a meeting as that specific employee.",
   "systems": [
    "helix"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "24",
     "label": "tools across identity, meetings, documents and grounding"
    },
    {
     "value": "≈11,000",
     "label": "lines of Rust in the meeting action server"
    },
    {
     "value": "3",
     "label": "Microsoft principals composed into one employee"
    }
   ],
   "lede": "An identity that can act Microsoft's Agent 365 lets an organisation give an AI a real identity in its tenant: an Entra Agent ID blueprint and an agent user with its own mailbox, Teams presence and licence. For Helix, making that identity do things turned out to involve three Microsoft principals, combinations the platform rejects, and preview behaviour the documentation did not cover. I decided to probe the real tenant, keep the wire traffic, and build only on the paths that worked. I provisioned the employee with Microsoft's tooling and configured it on their platform; what I built is everything that lets it act. design <figure class=\"dv-figure\" aria-label=\"Microsoft's part and mine\" <div style=\"display: flex; flex-direction: column; gap: 10px; margin-top: 0.8rem\"",
   "quote": "An identity layer that spoofs is no identity layer.",
   "evidence": [
    "Identity for AI agents in Microsoft 365 and Entra: a digital employee under Agent 365 composed from 3 Microsoft principals.",
    "MCP server design: about 11,000 lines of Rust with 24 tools through which any model acts in a meeting as one named employee without holding a token.",
    "Tenant provisioning automation: an installer that stops with a named reason rather than provision a half-configured identity."
   ],
   "technology_kind": "platform"
  },
  {
   "url": "https://coreyjames.ai/technologies/microsoft-azure/",
   "kind": "technology",
   "title": "Microsoft Azure",
   "subtitle": "Azure hosts the Windows side of my Teams integration: a media bridge with managed identity, vault-held secrets and authenticated access.",
   "systems": [
    "helix",
    "auth-and-access-plane"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "91,643",
     "label": "buffers carried in a 30-minute soak, Azure to my host"
    },
    {
     "value": "50.001/s",
     "label": "buffer rate held across the soak"
    },
    {
     "value": "11",
     "label": "job definitions removed and credentials revoked by one cleanup"
    }
   ],
   "lede": "A media bridge on a Windows VM Microsoft Teams hands raw call audio only to a Windows application built on Microsoft's real-time media SDK. The speech models and conversation engine behind Helix run on Linux GPUs, and I was not going to send call audio to someone else's AI service to get around that. I put the smallest possible piece in Azure and kept the brain on my own hardware. That piece is a .NET 8 media bridge on an Azure Windows Server virtual machine. The region turned down two smaller VM sizes for lack of capacity, so it runs on a larger general-purpose size. It carries call audio to my GPU host over one authenticated full-duplex WebSocket per call",
   "quote": "I use the cloud for exactly the part of a system that has to live there.",
   "evidence": [
    "Cloud architecture with a minimal footprint: only the Windows media bridge on Azure, with managed identity, Key Vault and no open inbound ports.",
    "Soak testing for real-time media: 91,643 buffers in a 30-minute soak at 50.001 per second with zero stalls.",
    "Ephemeral compute for AI jobs: Container Apps Jobs that exist only for their run, with cleanup checks leaving 0 executions active."
   ],
   "technology_kind": "platform"
  },
  {
   "url": "https://coreyjames.ai/technologies/microsoft-copilot-studio/",
   "kind": "technology",
   "title": "Microsoft Copilot Studio",
   "subtitle": "I expose a trimmed, authenticated tool surface to Microsoft Copilot Studio through an edge proxy, and worked out from the wire why its connector stalled after initialisation.",
   "systems": [
    "auth-and-access-plane"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "≈300",
     "label": "lines in the edge proxy"
    },
    {
     "value": "21",
     "label": "tools for desktop assistants, over a local transport"
    },
    {
     "value": "8",
     "label": "tools offered to Copilot Studio"
    }
   ],
   "lede": "Reading the connector from the wire I wanted Microsoft Copilot Studio agents to call tools on my private MCP server in the Auth and access plane, and I wanted that server to accept no public connection. The standard MCP OAuth path stalled right after initialize , and Copilot Studio's MCP connector was thinly documented. I decided to work out its behaviour from the wire and build around what it actually does. I read the connector's traffic end to end in edge logs and wrote it down as observed fact, which made each proxy decision traceable to something the connector does. design <figure class=\"dv-figure\" aria-label=\"What the connector does, and the answer to each\" <div style=\"display: flex; flex-direction: column; gap: 10px; margin-top:",
   "quote": "When a vendor platform is under-documented, I learn it from the wire.",
   "evidence": [
    "Reverse-engineering vendor integrations: Copilot Studio's MCP connector behaviour worked out from edge logs and answered by an edge proxy of about 300 lines.",
    "Zero-trust and zero-inbound networking: a private tool server reachable only through a tunnel, with tenant-pinned Entra token checks at the edge.",
    "MCP tool surface design: 21 tools for desktop assistants and a trimmed 8-tool surface shaped for Copilot Studio."
   ],
   "technology_kind": "platform"
  },
  {
   "url": "https://coreyjames.ai/technologies/microsoft-entra-id/",
   "kind": "technology",
   "title": "Microsoft Entra ID",
   "subtitle": "Entra Agent ID gives my digital employee its identity; I compose the Microsoft principals it involves into paths the platform actually accepts.",
   "systems": [
    "helix",
    "auth-and-access-plane"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "3",
     "label": "Microsoft principals composed for one employee"
    }
   ],
   "lede": "An agent identity for each employee Helix needed an AI that acts in Microsoft 365 as one named employee, with its own identity and no shared super-account. I decided Microsoft would stay the permission authority and my code would compose and check identities. Each digital employee is an agent identity in the tenant under Microsoft Entra Agent ID. The meeting action server signs certificate client assertions against the employee's agent blueprint and receives that employee's own Microsoft Graph tokens. Calling and attributed actions use separate token kinds, matching what the platform expects for each, and the tokens never reach a model. design <figure class=\"dv-figure\" aria-label=\"The employee's token path\" <div style=\"display: flex; align-items: center; gap: 6px; margin-top: 0.8rem\" <div style=\"display: flex;",
   "quote": "I keep credentials out of model context and identity checks at the boundary where requests enter.",
   "evidence": [
    "Microsoft Graph and Entra integration: each digital employee an Entra Agent ID identity receiving its own Graph tokens through certificate assertions.",
    "Edge token validation: tenant-pinned RS256 checks with WebCrypto against cached signing keys, refusing tokens from other tenants or applications.",
    "Credential isolation for AI agents: tokens checked in process and never passed to a model."
   ],
   "technology_kind": "platform"
  },
  {
   "url": "https://coreyjames.ai/technologies/microsoft-graph/",
   "kind": "technology",
   "title": "Microsoft Graph",
   "subtitle": "Microsoft Graph is how the employee reads mail, posts in meeting chat and answers calls, with tokens minted per employee and validated before use.",
   "systems": [
    "helix"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "24",
     "label": "tools on the digital-employee server through which a model acts as the employee"
    }
   ],
   "lede": "Answering calls as the employee Helix puts a governed digital employee into Teams calls and meetings, and Microsoft Graph is the surface it acts through. The first problem was calling: no single Microsoft principal can both answer a call as the employee and own the media session. I composed two Graph Communications clients. The employee's identity answers inbound calls under its own name, and a transport-only client owns the native media platform that carries the audio. That composition is the core of A self-hosted colleague in a Teams call. design <figure class=\"dv-figure\" aria-label=\"Who answers an inbound call and who rings on an outbound one\" <div style=\"display: grid; gap: 0.4rem\" <span class=\"eyebrow\" Inbound</span <div style=\"display: flex; align-items: center; gap: 0; margin-top:",
   "quote": "I can turn Microsoft Graph into a governed action surface for an AI colleague, where every call, message and screen share is attributed to one identity and grounded in what Graph reports.",
   "evidence": [
    "Microsoft Graph and Entra integration: two composed Graph Communications clients, so a digital employee answers Teams calls under its own identity while a transport-only client owns the media.",
    "Identity for AI agents in Microsoft Entra: a Rust MCP server of 24 meeting tools where every call names the acting employee and the server mints that employee's token by certificate assertion.",
    "Fail-closed agent tool design: a room-state projector over Graph participant data, joins counted only once the roster shows the employee, and a typed refusal where Graph offers no way to raise a hand."
   ],
   "technology_kind": "platform"
  },
  {
   "url": "https://coreyjames.ai/technologies/microsoft-real-time-media-sdk/",
   "kind": "technology",
   "title": "Microsoft real-time media SDK",
   "subtitle": "A .NET 8 media service on Microsoft's real-time media SDK, handling unmanaged buffers on the SDK's clock and joined to a Linux voice engine across clouds.",
   "systems": [
    "helix"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "91,643",
     "label": "audio buffers through the soak, zero receive stalls and zero reconnects"
    },
    {
     "value": "50.001",
     "label": "buffers a second against the SDK's 20-millisecond cadence"
    },
    {
     "value": "8,833",
     "label": "buffers through a forced mid-call reconnect, with one 250 ms retry"
    },
    {
     "value": "65–67 ms",
     "label": "media round trip on one probe"
    }
   ],
   "lede": "A media-only bridge on Windows Helix runs its speech models and conversation engine on Linux GPUs I own, and Microsoft Teams hands raw call audio only to a Windows application built on Microsoft's real-time media SDK. I refused to send call audio to a hosted AI service to avoid that mismatch, so I built a bridge and kept the brain at home. The bridge is a .NET 8 solution of six projects (host, calls, media, transport, contracts and unit tests) on a Microsoft Azure Windows machine. Its only job is media: join the call, receive and send audio frames, and publish the agent's screen as video. Every decision stays with the engine on Linux, so the Windows side can be",
   "quote": "A colleague who answers a question from twenty seconds ago is worse than one who asks you to repeat it.",
   "evidence": [
    "Microsoft Teams real-time media: a .NET 8 bridge on Microsoft's real-time media SDK that moved 91,643 audio buffers at 50.001 a second from Azure to Linux with zero receive stalls.",
    "Real-time audio with unmanaged memory: buffers allocated and freed under the SDK's ownership rules, a paced 20-millisecond pump and bounded channels for back-pressure.",
    "Failure testing for real-time systems: a forced mid-call reconnect inside the same call, 8,833 buffers with one 250 ms retry, and microphone audio from the break dropped.",
    "Cross-language wire protocols: one authenticated WebSocket per call carrying a binary media protocol implemented in C# and Rust, tested byte for byte against shared golden vectors."
   ],
   "technology_kind": "framework"
  },
  {
   "url": "https://coreyjames.ai/technologies/microsoft-teams/",
   "kind": "technology",
   "title": "Microsoft Teams",
   "subtitle": "People call my digital employee in Teams and it answers; they invite it to meetings and it presents, shares a screen and calls on raised hands. It does not raise its own, because the platform offers no way to.",
   "systems": [
    "helix",
    "auth-and-access-plane"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "13",
     "label": "meeting actions with exact schemas, each naming the acting employee"
    },
    {
     "value": "30 min",
     "label": "Teams media soak from Azure to Linux"
    },
    {
     "value": "0",
     "label": "receive stalls through the soak and a forced mid-call reconnect"
    }
   ],
   "lede": "Answering calls like a colleague Helix exists because I wanted one AI colleague that shows up where people already work, under an identity the organisation governs, and behaves in a call and a meeting the way a colleague does. People call the digital employee in Teams and it answers. Call audio crosses from a .NET 8 service on the Microsoft real-time media SDK to a Rust voice engine on my GPUs. When someone talks over the agent, it stops. A Teams call is one more implementation of the engine's sealed audio interface, so the same conversation engine runs on a desk microphone and in Teams. See A self-hosted colleague in a Teams call. design <figure class=\"dv-figure\" aria-label=\"One conversation engine behind",
   "quote": "Reporting a hand as raised from local state would be a lie nobody in the meeting could see through.",
   "evidence": [
    "Microsoft Teams real-time media: a self-hosted AI participant whose Rust voice engine treats a Teams call as one more implementation of its sealed audio interface, with a 30 min soak and 0 receive stalls.",
    "AI agents in Microsoft Teams meetings: 13 meeting actions with exact schemas, each naming the acting employee, each counted done only when it works in a real meeting.",
    "Teams app development: a meeting-stage app on TeamsJS with an authenticated relay so the agent drives a deck, and a React personal tab signed in through Teams single sign-on with MSAL and PKCE.",
    "Screen-sharing pipelines: a headless Linux desktop captured with FFmpeg and framed as H.264 under one typed frame contract across Linux, Windows and Teams."
   ],
   "technology_kind": "platform"
  },
  {
   "url": "https://coreyjames.ai/technologies/ml-evaluation-methodology/",
   "kind": "technology",
   "title": "ML evaluation methodology",
   "subtitle": "Frozen evaluation sets, pre-registered targets, known-answer controls, a list of results never to quote, and a baseline built to beat me. It tied, and the tie is what I publish.",
   "systems": [
    "capabilities-model"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "41,990",
     "label": "tokens of tool catalog the model replaces"
    },
    {
     "value": "15",
     "label": "buried-request probes"
    },
    {
     "value": "5",
     "label": "embedding models in the bake-off"
    },
    {
     "value": "4 arms",
     "label": "crossed over across two cards to attribute a throughput gain"
    }
   ],
   "lede": "An instrument fixed before the first result Capabilities model replaces a whole tool catalog with one discovery tool backed by a fine-tuned 0.6-billion-parameter open-weight base model. A model like that is only worth publishing if its evaluation can catch it being wrong, so I built the evaluation as an instrument with fixed rules before any result came in. Its core is a frozen pair: a held-out query set and a set of long probes in which the needed tool is buried deep inside a verbose request. Nothing about the instrument could move to help the model. design <figure class=\"dv-figure\" aria-label=\"The frozen pair\" <div class=\"dv-two\" <div <span class=\"eyebrow\" Held-out queries</span <div aria-hidden=\"true\" style=\"display: grid; grid-template-columns: repeat(32, minmax(0, 9px)); gap: 2px; margin-top:",
   "quote": "Known-answer controls run inside the harness so it can catch the team as readily as the model.",
   "evidence": [
    "ML evaluation methodology: a frozen held-out set and 15 buried-request probes fixed before any result, with known-answer controls that stopped the whole matrix when one failed.",
    "Baseline engineering: a dense and BM25 fusion baseline with every constant swept and an embedder chosen from 5 in a bake-off, which tied the fine-tuned model.",
    "Reporting negative results: published 0.67 against 0.90 recall on buried requests and 6.9 against a 200 requests-a-second serving target."
   ],
   "technology_kind": "discipline"
  },
  {
   "url": "https://coreyjames.ai/technologies/model-context-protocol-mcp/",
   "kind": "technology",
   "title": "Model Context Protocol (MCP)",
   "subtitle": "Every agent in my estate reaches every tool through MCP: a gateway of 475 tools, generated servers, a product server ported to .NET, and a single discovery tool backed by a model.",
   "systems": [
    "agentos",
    "agent-swarm",
    "helix",
    "fafohive",
    "fafo-core",
    "inference-fabric",
    "capabilities-model",
    "auth-and-access-plane"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "~45",
     "label": "work-lifecycle actions across eleven AgentOS tools"
    },
    {
     "value": "~180",
     "label": "actions across 18 FAFO Core tools, dispatch compiled from YAML"
    },
    {
     "value": "24",
     "label": "tools on the digital-employee server, 13 of them meeting actions"
    }
   ],
   "lede": "One endpoint for every agent seat FAFOHive is the single endpoint every managed agent seat in my estate connects to, because I wanted one trust model for every tool an agent can reach. The provider tools sit under stable namespaces, and every provider call is durably accounted, so a restart does not repeat one. See Agents with real tools and no keys. I design tools around jobs: in one module I threw away 83 generated endpoint tools for about fifteen designed ones, a set that later grew to thirty-six. Tool descriptions state their cost and pass the provider's errors through verbatim, so the agent reasons over real failures. When the SDK's streaming transport broke on every container restart, I replaced",
   "quote": "I treat MCP as an engineering surface with identity, cost and failure designed in.",
   "evidence": [
    "MCP server design: one endpoint for every managed agent seat serving 475 tools, with provider calls durably accounted so a restart does not repeat one, over a stateless per-request transport.",
    "Agent orchestration over MCP: the AgentOS work lifecycle exposed as about 45 actions across eleven tools, with caller identity derived on the server, idempotency keys and receipts.",
    "Tool-schema context cost reduction: a 41,990-token catalog collapsed into one discovery tool of about 100 tokens, its description capped by a test at 520 characters.",
    "Tool synthesis and governed API integration: about 180 actions across 18 tools compiled from YAML schemas at build time, and a tool that emits new MCP tools."
   ],
   "technology_kind": "protocol"
  },
  {
   "url": "https://coreyjames.ai/technologies/model-families-and-types/",
   "kind": "technology",
   "title": "Model families and types",
   "subtitle": "I pick a model for the job and the hardware it has to run on, then I change it until it fits.",
   "systems": [
    "helix",
    "fafohive",
    "inference-fabric",
    "activekv",
    "capabilities-model"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "3B",
     "label": "active parameters per token, of 30B, in the mixture-of-experts build"
    },
    {
     "value": "1,024",
     "label": "dimensions in the memory search embedder"
    }
   ],
   "lede": "Depending on the job, I fine-tune a model, quantize it, convert it, build an inference engine for it, or measure it against alternatives. The work spans most of the model families in use today. Small dense models as routers My Capabilities model is a dense model of about half a billion parameters, fully fine-tuned so that a tool catalog lives in its weights. I trained a ladder of small dense models at sub-billion, half-billion and low-billion sizes, and chose the size from measured recall and training time. A half-billion-parameter model became a tool index because a full fine-tune takes minutes. design <blockquote class=\"dv-quote\" <p I size the model to the problem.</p </blockquote design <figure class=\"dv-figure\" aria-label=\"The router's size ladder\" <span",
   "quote": "I size the model to the problem.",
   "evidence": [
    "LLM quantization (FP8 and 4-bit): 4-bit and mixed 4-bit/FP8 builds of a 27B-class hybrid model on one 32 GB card, the all-4-bit build +36% throughput at +3.3% perplexity.",
    "Model selection across families: dense, mixture-of-experts at 3B of 30B active, hybrid recurrent-attention, embedding, speech and diffusion models from <1B to 70B+ parameters.",
    "Inference serving architecture: runtimes chosen per hardware and job, TensorRT-LLM and my own CUDA engine on NVIDIA, vLLM's XPU build and OpenVINO on Intel."
   ],
   "technology_kind": "model"
  },
  {
   "url": "https://coreyjames.ai/technologies/model-quantization/",
   "kind": "technology",
   "title": "Model quantization",
   "subtitle": "A published 4-bit-weight quantization that fits a 27B model on one 32 GB card for 36 percent more throughput at 3 percent perplexity cost, an INT8 compressed history tier for ActiveKV, and FP8 serving on NVIDIA.",
   "systems": [
    "inference-fabric",
    "activekv",
    "capabilities-model"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "8.4 GB",
     "label": "moved across PCIe per generated token at 128K on the exact path"
    },
    {
     "value": "0.0027",
     "label": "worst merged error, against a bound of 0.005"
    },
    {
     "value": "48",
     "label": "real samples the loss bound is checked on"
    },
    {
     "value": "512",
     "label": "own-task calibration samples for the router's FP8 and NVFP4 builds"
    }
   ],
   "lede": "A lossless tier first ActiveKV keeps attention history in host memory, so every decode step pays to move that history across PCIe. A smaller history buys time on every token, but only if the GPU can attend to the small form directly. I tried lossless compression first and let the bus arithmetic decide when a lossy format was worth its loss bound. design <figure class=\"dv-figure\" aria-label=\"The lossless tier: a plane uses few of BF16's exponents, so each exponent becomes a small index\" <div class=\"dv-two\" <div <span class=\"eyebrow\" BF16's 256 exponents · a 1,024-token plane uses at most 32</span <div style=\"display: grid; grid-template-columns: repeat(32, minmax(0, 1fr)); gap: 2px; margin-top: 0.8rem\" aria-hidden=\"true\" <i style=\"aspect-ratio: 1; border-radius: 2px; background: var(--rule)\" </i <i style=\"aspect-ratio:",
   "quote": "On a transfer-bound path a slower kernel that moves fewer bytes wins.",
   "evidence": [
    "LLM quantization: an 8-bit KV-cache page format designed around its attention kernel, at a worst merged error of 0.0027 against a bound of 0.005.",
    "Attention kernel optimisation: matched experiments took an 8-bit prefill over a 32K-token tile from 18.69 ms to 8.74 ms, below the ~9.6 ms BF16 reference.",
    "Reproducible model artefacts: a published 4-bit build of a 27B model from 55.6 GB to 20.6 GB, round-to-nearest with no calibration so anyone can reproduce it.",
    "Precision chosen by measurement: FP8 weights and key-value cache over INT4 on the Blackwell cards, with every artefact reproducing byte for byte."
   ],
   "technology_kind": "discipline"
  },
  {
   "url": "https://coreyjames.ai/technologies/multi-agent-system-architecture-and-orchestration/",
   "kind": "technology",
   "title": "Multi-agent system architecture and orchestration",
   "subtitle": "A governance control plane, a persona-driven runtime and a voice-first collaboration shell: three ways I have organised many agents around one body of work, with the state outside any model's head.",
   "systems": [
    "agentos",
    "agent-swarm",
    "helix"
   ],
   "technologies": [],
   "stats": [],
   "lede": "Governance, a runtime and collaboration: each time, I treated many agents as a distributed system held to the accountability I expect from people, with explicit state, separated duties, traceable messages and failure domains drawn on purpose. Governance: team state in a work graph AgentOS started from a diagnosis: long agent runs drift because the lead agent has to hold every teammate's state in its head, and past some horizon it forgets one. I moved team state into a PostgreSQL work graph. design <blockquote class=\"dv-quote\" <p Team state lives in a database, because an agent that must remember everyone's status eventually forgets one.</p </blockquote Seats from more than one vendor run in containers on more than one machine under one contract,",
   "quote": "Team state lives in a database, because an agent that must remember everyone's status eventually forgets one.",
   "evidence": [
    "Agent orchestration: team state for long agent runs moved into a PostgreSQL work graph, with each seat given a small, freshly rendered job.",
    "Separation of duties for AI work: separate builder and checker seats, an adversarial seat on a different vendor's model and a gatekeeper that judges only what was delivered.",
    "Multi-agent collaboration systems: signed agent messages that carry their call chain and refuse delegation loops, and a council where models deliberate and ratify a decision."
   ],
   "technology_kind": "discipline"
  },
  {
   "url": "https://coreyjames.ai/technologies/multi-vendor-llm-integration/",
   "kind": "technology",
   "title": "Multi-vendor LLM integration",
   "subtitle": "Three frontier model families and local open-weight models run side by side in my programs, through subscription sessions, API seats and my own GPUs, with a terms-of-service firewall deciding which traffic may go where.",
   "systems": [
    "fafohive",
    "auth-and-access-plane"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "30 days",
     "label": "a temporary client stays pending, because some assistants never register again"
    },
    {
     "value": "5",
     "label": "language-model providers behind one interface"
    },
    {
     "value": "3",
     "label": "frontier model families whose tools and apps come in through one flow"
    }
   ],
   "lede": "One way in for every assistant Auth and access plane had to let several vendors' assistants into one private tool estate: the command-line tools and desktop apps of three frontier model families, an agentic IDE and Microsoft Copilot Studio. Each behaves differently within what the standards allow. design <blockquote class=\"dv-quote\" <p I decided to keep one authorization flow and move every vendor difference into a client profile held in configuration.</p </blockquote design <figure class=\"dv-figure\" aria-label=\"Every assistant through one authorization flow\" <div style=\"display: grid; grid-template-columns: minmax(0, 8.5rem) minmax(0, 1fr) 0; gap: 0.45rem 0.6rem; align-items: center; margin-top: 0.6rem\" <span class=\"lbl\" style=\"font-size: 0.78rem\" Frontier command-line tools</span <div style=\"display: flex; gap: 2px; height: 16px; min-width: 0\" <span style=\"flex: 1; border-radius: 4px; background: color-mix(in srgb,",
   "quote": "I decided to keep one authorization flow and move every vendor difference into a client profile held in configuration.",
   "evidence": [
    "OAuth and identity architecture: one authorization flow for assistants from 3 frontier model families, an agentic IDE and Copilot Studio, vendor differences held in client profiles.",
    "Multi-vendor LLM integration: 5 language-model providers behind one interface, any of them replaceable by a local OpenAI-compatible server with no change to callers.",
    "Resilient API clients: one retry policy that backs off on transport, rate-limit and server errors and returns authentication, bad-request and parse errors at once."
   ],
   "technology_kind": "discipline"
  },
  {
   "url": "https://coreyjames.ai/technologies/multilingual-embedding-model/",
   "kind": "technology",
   "title": "Multilingual embedding model",
   "subtitle": "the multilingual embedding model is the embedding model behind my code and reference search, served from a local text-embedding server.",
   "systems": [
    "fafohive",
    "fafo-core"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "19,204",
     "label": "documents in the code index for my monorepo"
    },
    {
     "value": "294,362",
     "label": "chunks in that index, embedded with the multilingual embedding model"
    },
    {
     "value": "294,033",
     "label": "of those chunks also covered by the code graph"
    }
   ],
   "lede": "I treat an embedding model as a service with a contract and a failure mode, and I engineered how the model is served, cached and degraded around that. I did not train or fine-tune the multilingual embedding model. Serving it out of process FAFOHive searches code, reference documents and stored observations for every agent seat in my estate, and every one of those searches starts with a dense embedding from the multilingual embedding model. The first versions tied GPU work to the life of the memory service, so I moved the model out of process, which keeps the service's lifecycle independent of the model's. design <figure class=\"dv-figure\" aria-label=\"Three ways the model was served, drawn as processes; the out-of-process server was",
   "quote": "The embedding dimension is a contract every consumer relies on, which let the serving backend change underneath without touching stored vectors or callers.",
   "evidence": [
    "Embedding model serving: a multilingual embedding model moved out of process behind a local text-embedding server, with a cache so only misses reach the GPU.",
    "Semantic code search: a code index of 19,204 documents and 294,362 chunks embedded for search across my monorepo."
   ],
   "technology_kind": "model"
  },
  {
   "url": "https://coreyjames.ai/technologies/network-egress-confinement/",
   "kind": "technology",
   "title": "Network egress confinement",
   "subtitle": "The most privileged agent seat in my estate is fenced: its only way out is a proxy that allows a handful of exact destinations.",
   "systems": [
    "agentos"
   ],
   "technologies": [],
   "stats": [],
   "lede": "A fence round the most privileged seat AgentOS runs coding agents in containers, and the team-lead seat is the most privileged of them. It directs other agents and uses the estate's governance tools. My view was that a seat like that should reach its model vendor and nothing else, so I built deny-by-default network confinement for it. The seat's container sits on an internal network with no route out. Its one exit is an allow-listing proxy, and the proxy carries one thing: an encrypted connection to the seat's vendor endpoints. design <blockquote class=\"dv-quote\" <p I treat the agent's network as an attack surface and start from deny-all with one named exit.</p </blockquote design <figure class=\"dv-figure\" aria-label=\"What leaves the seat\" <div",
   "quote": "I treat the agent's network as an attack surface and start from deny-all with one named exit.",
   "evidence": [
    "Zero-trust and egress control: deny-by-default network confinement for the most privileged agent seat, whose one exit is an allow-listing proxy to its vendor endpoints.",
    "Allow-list bypass prevention: names resolving into private address space, mismatched TLS host names, wildcards and address literals all refused.",
    "Proof-driven rollout: every rollout probes that the vendor path succeeds and every blocked category fails, and a preflight checks the proxy image identity before a seat starts."
   ],
   "technology_kind": "discipline"
  },
  {
   "url": "https://coreyjames.ai/technologies/nginx/",
   "kind": "technology",
   "title": "NGINX",
   "subtitle": "NGINX fronts the OAuth server and the estate's other web services with TLS and rate limits, ahead of any application code.",
   "systems": [
    "auth-and-access-plane",
    "fafohive"
   ],
   "technologies": [],
   "stats": [],
   "lede": "Layering controls in front of the OAuth server Auth and access plane needed the OAuth server and the estate's other web services protected in a way that does not depend on each application getting security right. I put NGINX in front of them and the service sandbox behind them. Requests arrive through outbound Cloudflare Tunnel connections, which leaves no open inbound port anywhere in the estate. Behind NGINX, the OAuth server runs under a locked-down systemd unit, so a flaw in the application still runs without new privileges on a read-only system. The OAuth server's proxy configuration lives in version control beside its source, so a proxy change travels with the code it protects. The consent design these controls protect",
   "quote": "I use NGINX as a deliberate security and traffic-shaping layer and put each control where it is cheapest and hardest to bypass.",
   "evidence": [
    "Reverse proxy security hardening: NGINX in front of an OAuth server with TLS, HSTS preload, security headers and per-zone rate limits, chosen over an application limiter so abuse is turned away before parsing.",
    "Zero-trust and zero-inbound networking: requests arriving only through outbound tunnels with no open inbound port, and operator control surfaces denied to every outside request at the proxy.",
    "Service sandboxing with systemd: a locked-down unit behind the proxy with no new privileges and a read-only system, and credentials delivered through systemd's credential mechanism."
   ],
   "technology_kind": "platform"
  },
  {
   "url": "https://coreyjames.ai/technologies/nvidia-blackwell-gpus/",
   "kind": "technology",
   "title": "NVIDIA Blackwell GPUs",
   "subtitle": "Consumer NVIDIA Blackwell GPUs carried the Inference Fabric, the capabilities model and early ActiveKV work, first on one card and then on two mismatched cards draining one broker queue.",
   "systems": [
    "inference-fabric",
    "capabilities-model",
    "fafo-core",
    "helix",
    "activekv"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "96.9%",
     "label": "streaming-multiprocessor utilisation on one card"
    },
    {
     "value": "~65,000",
     "label": "tokens a second held for ten hours on one card"
    },
    {
     "value": "4.95M",
     "label": "tasks in that ten-hour run, with zero retries"
    },
    {
     "value": "3–4 h",
     "label": "to build the shared TensorRT-LLM image from source"
    }
   ],
   "lede": "I have run consumer Blackwell GPUs hard in five roles: bulk generation, a co-resident custom decoder, real-time speech, provisioned compute and early cache-offload work. In each I measured what the card does and built to that; cache windows, memory left beside a resident model and utilisation all come from the card. Bulk generation on one card Inference Fabric asked how much of a consumer Blackwell GPU's real throughput a disciplined serving design could reach on bulk generation. On one 32 GB card the 7-billion-parameter dense model ran in FP8. design <figure class=\"dv-figure\" aria-label=\"What I built for the card\" <div class=\"dv-two\" <div <span class=\"eyebrow\" The card</span <div class=\"gpu\" style=\"margin-top: 0.8rem\" <span class=\"eyebrow\" 32 GB card</span <div class=\"die\" style=\"grid-template-columns: repeat(16, 1fr)\" <b",
   "quote": "Mismatched cards are where a plain queue breaks down.",
   "evidence": [
    "NVIDIA Blackwell development: TensorRT-LLM built from source for compute capability 12.0 and kernels compiled with CUDA 13.1 as native SM 120 binaries, other GPUs refused at runtime.",
    "High-throughput batch inference: one 32 GB card at 96.9% streaming-multiprocessor utilisation, holding ~65,000 tokens a second for ten hours through 4.95M tasks with zero retries.",
    "Heterogeneous GPU scheduling: a 32 GB and a 16 GB card on one broker queue, each described by four integers, reaching a five-minute mean of 163,000 tokens a second.",
    "GPU memory co-residency: a router engine in 2,740 MiB beside a resident model of about 30B, serving a burst of 2,048 simultaneous clients with none rejected or corrupted."
   ],
   "technology_kind": "hardware"
  },
  {
   "url": "https://coreyjames.ai/technologies/nvidia-nsight-systems/",
   "kind": "technology",
   "title": "NVIDIA Nsight Systems",
   "subtitle": "Nsight traces are where I found what the engine was actually doing, and where I learned to check that the trace was not itself the cause.",
   "systems": [
    "inference-fabric"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "44K",
     "label": "tokens a second on one NVIDIA Blackwell GPU at the start, 7B dense model in FP8"
    },
    {
     "value": "163K",
     "label": "five-minute mean across two NVIDIA Blackwell GPUs at the end"
    },
    {
     "value": "<1%",
     "label": "gained by custom CUDA graphs over eager execution"
    },
    {
     "value": "6.8%",
     "label": "slower with the key-value cache offloaded to the host"
    }
   ],
   "lede": "Proving the runtime's hot-path rules Inference Fabric depended on a GPU runtime that had to stay saturated, and some of its properties could only be settled with a timeline. The runtime is a C++ layer at the NVIDIA TensorRT boundary, driven from Rust, feeding NVIDIA TensorRT-LLM for generation and raw TensorRT for hidden-state extraction. I gave its code two rules: after warm-up the decode loop allocates no memory, and it never synchronises the compute stream. The rules live in code and stop regressions; a timeline trace shows the property holds. design <figure class=\"dv-figure\" aria-label=\"Memory allocations across warm-up and the steady state\" <span class=\"eyebrow\" Allocations per step, as a trace shows them</span <div style=\"display: grid; grid-template-columns: 3fr 7fr; gap: 6px; margin-top:",
   "quote": "\"Zero allocations after warm-up\" is easy to assert and easy to break in a later change, and a trace settles it.",
   "evidence": [
    "GPU profiling (Nsight): timeline traces and gap analysis of idle time between kernels on an NVIDIA Blackwell GPU, used as proof that the decode loop allocates nothing after warm-up and never synchronises the stream.",
    "Performance benchmarking methodology: eager execution and custom CUDA graphs captured on the same card, graphs dropped for under 1% gain, host KV-cache offload dropped at 6.8% slower.",
    "GPU inference optimisation: part of a programme that took a 7-billion-parameter FP8 model from about 44K tokens a second on one NVIDIA Blackwell GPU to a 163K five-minute mean on two."
   ],
   "technology_kind": "platform"
  },
  {
   "url": "https://coreyjames.ai/technologies/nvidia-tensorrt-llm/",
   "kind": "technology",
   "title": "NVIDIA TensorRT-LLM",
   "subtitle": "TensorRT-LLM is the engine under the Inference Fabric. I never touched its kernels; everything I gained came from how work was fed to it, and I tried it first for the capabilities model before closing that path on evidence.",
   "systems": [
    "inference-fabric",
    "capabilities-model",
    "fafo-core"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "163K",
     "label": "tokens a second, five-minute mean across two NVIDIA Blackwell GPUs, from about 44K on one"
    },
    {
     "value": "3,840",
     "label": "input tokens in the long-prompt tiers"
    },
    {
     "value": "1,000×",
     "label": "the worst weight corruption the vendor conversion caused on affected tensors"
    }
   ],
   "lede": "Engineering everything around the engine Inference Fabric started from stock TensorRT-LLM set up the obvious way, which left most of a consumer GPU idle on bulk generation. My view was that the ceiling sat around the engine, so I kept NVIDIA's kernels and engineered everything else. My C++ layer drives the engine through its Executor API from a Rust service and refuses any engine configuration that leans on defaults, so a mis-sized engine is refused up front. I changed one layer at a time on a 7-billion-parameter dense model in FP8. An engine tier sweep found the per-step token budget to be the largest lever on the engine side, and it is the first lever I measure since. See From",
   "quote": "I get the most from NVIDIA's serving stack by engineering what surrounds it, and I judge it fairly when it does not fit.",
   "evidence": [
    "TensorRT and TensorRT-LLM engineering: NVIDIA's kernels kept and everything around them engineered, from about 44K to a 163K tokens-a-second five-minute mean across two NVIDIA Blackwell GPUs.",
    "Inference serving architecture: per-card engine tiers from one calibrated FP8 checkpoint, up to 4,096 sequences and 524,000 tokens per step on the 32 GB card, each engine carrying a contract of its limits.",
    "Prefix reuse in LLM serving: shared prompt prefixes measured at 40 to 56 percent more throughput on the larger card with 128-token prompts, which is why the broker groups work by prefix.",
    "Vendor technology evaluation: TensorRT-LLM tried first for the capabilities model and closed on three findings, including weights corrupted up to 1,000x by conversion and 56 against 492 requests a second."
   ],
   "technology_kind": "runtime"
  },
  {
   "url": "https://coreyjames.ai/technologies/nvidia-tensorrt/",
   "kind": "technology",
   "title": "NVIDIA TensorRT",
   "subtitle": "Raw TensorRT backs the single-pass hidden-state extraction mode in the Inference Fabric's runtime.",
   "systems": [
    "inference-fabric"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "6",
     "label": "lines added to the decoder definition to expose the hidden state"
    },
    {
     "value": "128",
     "label": "tokens per input across every extraction build"
    }
   ],
   "lede": "Going one level below the serving stack Inference Fabric needed to read a language model's internal representations for millions of sequences, and serving stacks are built to produce tokens. NVIDIA TensorRT-LLM carries decoding machinery that a single read has no use for, so I went one level down to raw TensorRT and built the extraction path around the engine itself. design <figure class=\"dv-figure\" aria-label=\"The serving stack against raw TensorRT for a single read\" <div style=\"display: grid; grid-template-columns: 7.5rem minmax(0, 1fr); gap: 0.8rem; align-items: center; margin-top: 0.6rem\" <span class=\"lbl\" Serving stack</span <div <div style=\"display: flex; gap: 3px; margin-top: 0\" <i style=\"flex: 2; height: 16px; border-radius: 4px; background: var(--tone)\" </i <i style=\"flex: 0.35; height: 16px; border-radius: 4px; background: color-mix(in srgb, var(--tone) 45%,",
   "quote": "I drop to NVIDIA's lower-level engine when the standard serving path is the wrong tool, and change the vendor graph only where it buys a capability.",
   "evidence": [
    "TensorRT and TensorRT-LLM engineering: six lines added to the decoder definition expose the hidden state as an extra engine output, with the generation path unchanged.",
    "High-throughput batch inference: extraction engines with no key-value cache and no generation, one forward pass over up to 8,192 sequences of 128 tokens, a million tokens per pass.",
    "Fail-closed GPU runtimes: a C++ runtime that measures how a loaded engine reads last-token positions and refuses to start on an ambiguous answer, with no allocation after warm-up."
   ],
   "technology_kind": "runtime"
  },
  {
   "url": "https://coreyjames.ai/technologies/nvme-cold-tier-storage/",
   "kind": "technology",
   "title": "NVMe (cold-tier storage)",
   "subtitle": "The broker's cold tier is NVMe: billions of queued tokens survive a restart in shape-pure order.",
   "systems": [
    "inference-fabric"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "0",
     "label": "shape switches while draining one backlog"
    },
    {
     "value": "0.42%",
     "label": "padding waste across that backlog"
    },
    {
     "value": "2",
     "label": "NVIDIA Blackwell GPUs fed from one cold tier"
    }
   ],
   "lede": "A cold tier laid out for how the GPUs read Inference Fabric put a broker between producers that submit millions of tokenised tasks and walk away, and GPU consumers that pull work as fast as they can process it. The two sides run at different speeds for hours. Producers burst far ahead of the GPUs, and the GPUs must never wait on a producer. A backlog of billions of tokens does not fit in memory, and losing it on a restart would mean regenerating hours of queued work. I gave the broker a cold tier on local NVMe: an append-only store of memory-mapped segments, with only the hot working set in RAM, so disk sets the backlog's size. Append-only writes",
   "quote": "I treat local NVMe as a deliberate tier in a throughput system, laid out for the way the consumer reads.",
   "evidence": [
    "NVMe as a storage tier for GPU pipelines: a broker cold tier of append-only, memory-mapped segments on local NVMe that keeps a backlog of billions of queued tokens across restarts.",
    "Message broker and queue design: work grouped by token shape before it reaches disk, so one backlog drained across two NVIDIA Blackwell GPUs with 0 shape switches and 0.42% padding waste.",
    "Distributed systems correctness: an item counted done only when its result was delivered and acknowledged, after which 12.3B tokens received matched 12.3B routed."
   ],
   "technology_kind": "hardware"
  },
  {
   "url": "https://coreyjames.ai/technologies/oauth-2-0/",
   "kind": "technology",
   "title": "OAuth 2.0",
   "subtitle": "I built an OAuth 2.0 authorization server for commercial AI assistants, with consent as the real control, and my memory gateway validates tokens from several issuers against published keys.",
   "systems": [
    "auth-and-access-plane",
    "fafohive",
    "fafo-core",
    "helix"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "30 days",
     "label": "a newly registered client waits for a person's approval before it lapses"
    }
   ],
   "lede": "An authorization server built around consent Auth and access plane exists because I wanted commercial AI assistants to reach my private tool estate through standard OAuth, with a person approving every grant. I built the authorization server. It implements the authorization-code grant with PKCE, with the S256 check written from primitives, plus client credentials, refresh tokens and revocation, with separate authentication paths for confidential and public clients. Tokens are RS256-signed JWTs. The signing key persists, so tokens survive restarts, and the public keys are published for every verifier. Assistants find the server through authorization-server and protected-resource metadata, register through dynamic client registration and name the resource they want, with a default when they do not. I set the pending-client lifetime",
   "quote": "The consent screen is the control point, so open registration works with every assistant and no token is issued without a person's approval.",
   "evidence": [
    "OAuth 2.0 and identity architecture: an authorization server with the authorization-code grant and PKCE, an S256 check written from primitives, client credentials, refresh tokens, revocation and RS256-signed JWTs.",
    "Dynamic client registration and consent design: discovery metadata and open registration for AI assistants, a pending client lapsing after 30 days without a person's approval, and no token issued without it.",
    "Zero-trust architecture: a protected MCP resource that introspects every bearer token on every request and refuses, with no cached allow, when introspection cannot answer.",
    "Delegated authorization for AI agents: offline multi-issuer token validation with a scope tree and one-time-code step-up, sub-agent tokens that end with their parent, and atomic refresh so no refresh token is spent twice."
   ],
   "technology_kind": "protocol"
  },
  {
   "url": "https://coreyjames.ai/technologies/observability-and-alerting/",
   "kind": "technology",
   "title": "Observability and alerting",
   "subtitle": "SMS alerting is wired to the service fleet, with a metrics stack and dashboards beside it, and a status dashboard that says plainly what each service is doing.",
   "systems": [
    "auth-and-access-plane",
    "inference-fabric",
    "agentos"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "12",
     "label": "scrape jobs across hosts, GPUs and inference nodes"
    },
    {
     "value": "0",
     "label": "tokens between received and routed after the accounting fix"
    }
   ],
   "lede": "Discovery wired to provisioning Auth and access plane holds the observability layer for an estate one person operates, and that shaped every choice: nothing may depend on someone watching a dashboard. My Rust services expose native metrics endpoints, and a containerised Prometheus scrapes them, covering hosts, GPUs and inference nodes. I wired discovery to provisioning. When the execution substrate stands up a GPU node, locally, on a LAN workstation or on rented cloud capacity, it writes the node into Prometheus's file-based service discovery and installs the host and GPU exporters on it, so a new node is monitored from its first minute with no one editing a scrape configuration. design <figure class=\"dv-figure\" aria-label=\"A new GPU node is scraped from its",
   "quote": "I instrument systems as I build them and treat the instrumentation as part of the product.",
   "evidence": [
    "Observability and alerting: Prometheus, Alertmanager and Grafana for an estate one person operates, 12 scrape jobs across hosts, GPUs and inference nodes, alerts paged to a phone by severity.",
    "Monitoring wired to provisioning: GPU nodes written into Prometheus file-based discovery with exporters installed as they are stood up, locally, on a LAN or in the cloud.",
    "Dashboards for GPU economics: Inference Fabric panels for padding waste, cache hit rate and tokens received against routed, the panel that showed 12.3B received and 12.3B routed.",
    "Cost attribution for AI work: AgentOS dashboards of cost and usage per role and per model, read from the governance database."
   ],
   "technology_kind": "discipline"
  },
  {
   "url": "https://coreyjames.ai/technologies/onednn/",
   "kind": "technology",
   "title": "oneDNN",
   "subtitle": "Patches to Intel's math library for a GPU architecture the ecosystem had not caught up with, each one held to bit-identical output.",
   "systems": [
    "activekv"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "20%",
     "label": "off cold 32,000-token prefill, outputs identical"
    },
    {
     "value": "48",
     "label": "special-value combinations behind the exact-arithmetic rewrite"
    }
   ],
   "lede": "Patching the vendor's library in the vendor's toolchain ActiveKV serves a 27-billion-parameter hybrid recurrent-attention open-weight model on one Intel Arc Pro GPU, and on that card prefill and the 4-bit-weight model path run their large matrix multiplications through Intel's oneDNN. The Intel Arc Pro GPU is a new architecture and the open kernel stack had gaps. I decided to patch oneDNN's own sources inside Intel's toolchain image, so the binary matches what the serving engine loads, and to gate every change on bit-identical output against the unpatched path, measured on the whole workload on a quiet benchmark host. The gate exists because of what sits above oneDNN: ActiveKV's exact mode must match fully resident attention bit for bit. design <figure",
   "quote": "A GEMM patch that moved a single bit would void every parity result built on it.",
   "evidence": [
    "Intel GPU and SYCL/oneAPI engineering: oneDNN patched inside Intel's toolchain image for Xe2, one added GEMM catalogue entry cutting cold 32,000-token prefill from 21.54 s to 17.23 s.",
    "Bit-exact numerical verification: every vendor-library patch gated on bit-identical output against the unpatched path, measured on the whole workload on a quiet host.",
    "LLM quantization (4-bit): a tighter W4A16 lowering in oneDNN, and an exact instruction-set arithmetic rewrite tested across 48 special-value combinations and kept at flat speed."
   ],
   "technology_kind": "runtime"
  },
  {
   "url": "https://coreyjames.ai/technologies/onnx-runtime/",
   "kind": "technology",
   "title": "ONNX Runtime",
   "subtitle": "ONNX Runtime serves embeddings in the evaluation harness and in the voice engine's lighter models.",
   "systems": [
    "helix",
    "capabilities-model"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "5",
     "label": "embedding models from four families in the baseline bake-off"
    }
   ],
   "lede": "A retrieval baseline strong enough to tie Capabilities model needed a classical retrieval baseline strong enough to beat the model it was compared with. I ran the baseline's dense embedding models through ONNX Runtime from Rust, using the ort crate with the CUDA execution provider, in the same harness and the same runtime as the model under test, so the comparison differs only in method. The prebuilt runtime package lacked GPU kernels for my card and would have pushed the baseline to the CPU, so I built ONNX Runtime myself. The embedding model came from a bake-off that replaced an incumbent chosen by habit, and it was fused with BM25 using weights found by sweep. The resulting baseline tied the",
   "quote": "A baseline's numerical settings are part of the experiment.",
   "evidence": [
    "Retrieval evaluation methodology: a dense-embedding baseline chosen in a five-model bake-off and fused with BM25 by sweep, run in the same harness as the model under test, tying it at recall 5 and 10.",
    "Numerical reproducibility: TF32 on the GPU path traced as the cause of a failed known-answer control, pinned off, and the whole experiment matrix rerun.",
    "Speech recognition and synthesis pipelines: small speech models run in process in a Rust voice engine through ONNX Runtime, with larger recognition and synthesis models as GPU services."
   ],
   "technology_kind": "runtime"
  },
  {
   "url": "https://coreyjames.ai/technologies/openai-compatible-api/",
   "kind": "technology",
   "title": "OpenAI-compatible API",
   "subtitle": "An OpenAI-compatible endpoint is the common shape my local models, the voice engine and ActiveKV present to callers.",
   "systems": [
    "agent-swarm",
    "helix",
    "activekv"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "32,768",
     "label": "tokens of model context the voice requests outgrew before the fix"
    }
   ],
   "lede": "One wire shape for every agent model In Agent Swarm agents use models from my own GPUs and from hosted providers, and I did not want provider-specific code anywhere in the agent loop. I standardised every model on the OpenAI-compatible chat and tool-calling interface, so routing, budgets and tool checks are written once. Local open-weight models served by vLLM already speak it. For hosted providers that do not, I built small bridge services that translate their APIs into the same shape, rate-limit in Redis, and register and deregister themselves, so the agent loop never learns a vendor's API. With one interface, the router picks an endpoint by policy and load. design <figure class=\"dv-figure\" aria-label=\"How the router narrows every endpoint to",
   "quote": "I use a common interface as an architectural boundary.",
   "evidence": [
    "Multi-provider LLM integration: local and hosted models standardised on the OpenAI-compatible chat and tool-calling interface, with bridge services translating providers and a router choosing by policy and load.",
    "Tool-calling validation: every returned tool call checked against its JSON Schema in strict mode before it runs, so a malformed call from a local model fails as an error.",
    "Real-time voice AI latency: a voice engine streaming clause by clause from an OpenAI-compatible endpoint, with a tool-selection step removed after a catalog overflowed a 32,768-token context."
   ],
   "technology_kind": "protocol"
  },
  {
   "url": "https://coreyjames.ai/technologies/openapi/",
   "kind": "technology",
   "title": "OpenAPI",
   "subtitle": "OpenAPI descriptions are the declarative input to my API integration platform and to the generated tool surfaces behind the memory gateway.",
   "systems": [
    "fafo-core",
    "fafohive"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "83",
     "label": "generated operations, kept internal"
    },
    {
     "value": "36",
     "label": "designed tools agents see"
    },
    {
     "value": "A dozen",
     "label": "semantic rules every manifest is checked against"
    }
   ],
   "lede": "A specification checked against behaviour In FAFO Core and Function Forge I built a platform that puts third-party APIs behind agent tools, and the first thing I decided was that an API's specification is a claim about the API. An OpenAPI 3.x document, or a hand-written seed for an API without one, is converted deterministically into a schema-checked manifest: operations, parameters, authentication and response shapes in one canonical format, checked against semantic rules. The platform's test catalogs include negative cases, so the gate itself is tested. design <figure class=\"dv-figure\" aria-label=\"The gate between a specification and an agent tool\" <div style=\"position: relative; display: grid; grid-template-columns: repeat(5, minmax(0, 1fr)); gap: 4px 6px; margin-top: 0.8rem\" <span aria-hidden=\"true\" style=\"position: absolute; left: calc(50% / 5);",
   "quote": "An OpenAPI document is a poor design for an agent's tools and no proof of what an API does.",
   "evidence": [
    "Tool synthesis and governed API integration: OpenAPI 3.x documents converted deterministically into schema-checked manifests, with agent tools only after an API's real behaviour is shown.",
    "MCP tool design for agents: 83 generated operations kept as a typed internal layer, and 36 designed tools shaped like an agent's jobs, each stating its cost formula and returning its actual cost."
   ],
   "technology_kind": "protocol"
  },
  {
   "url": "https://coreyjames.ai/technologies/performance-engineering-and-benchmarking/",
   "kind": "technology",
   "title": "Performance engineering and benchmarking",
   "subtitle": "Fixed model, one variable at a time, negatives beside positives, and an intake screen that rejects gains tuned to the test fixture.",
   "systems": [
    "activekv",
    "inference-fabric",
    "fafo-core",
    "capabilities-model"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "16",
     "label": "cells in the frozen workload matrix"
    },
    {
     "value": "196 → 0",
     "label": "deadlocks in one bulk update after a unique index"
    },
    {
     "value": "7B",
     "label": "dense model in FP8, held fixed across every step"
    }
   ],
   "lede": "A measurement doctrine for ActiveKV In ActiveKV one metric, inter-token latency, kept declaring success or failure on its own and misled everyone, me included. I wrote a measurement doctrine to fix that, and comparison tables are generated from run data. design <figure class=\"dv-figure\" aria-label=\"The measurement doctrine: every A/B reported on four metrics, measured on two hosts with different jobs\" <div class=\"dv-two\" <div <span class=\"eyebrow\" One A/B, four metrics</span <div class=\"dv-bars\" style=\"grid-template-columns: 7.5rem minmax(0, 1fr) 0\" <span time to first token</span <span style=\"display: grid; gap: 3px\" <span class=\"bar\" style=\"width: 90%\" </span <span class=\"bar on\" style=\"width: 72%\" </span </span <span </span <span inter-token latency</span <span style=\"display: grid; gap: 3px\" <span class=\"bar\" style=\"width: 60%\" </span <span class=\"bar on\" style=\"width: 66%\" </span </span <span",
   "quote": "I design the instrument, the baseline and the reading rules as carefully as the system under test, and I retract my own conclusions when the instrument turns out to be the cause.",
   "evidence": [
    "Performance benchmarking methodology: a frozen 16-cell workload matrix, four metrics on every report and an intake screen that rejects gains keyed to benchmark fixture sizes.",
    "GPU inference optimisation: one layer changed at a time on a fixed 7B dense model in FP8, from 44K to 163K tokens per second, with three losing ideas kept beside the wins.",
    "PostgreSQL performance tuning: a bulk update diagnosed from PostgreSQL's own tuple counts rather than queue counters, taken from 196 deadlocks to 0 by one unique index.",
    "Load testing under concurrency: a load ladder from 1 to 2,048 concurrent clients set as an acceptance requirement, with the full burst served beside the main model."
   ],
   "technology_kind": "discipline"
  },
  {
   "url": "https://coreyjames.ai/technologies/pgvector/",
   "kind": "technology",
   "title": "pgvector",
   "subtitle": "Vector search inside PostgreSQL backs the memory service's hybrid retrieval and the capabilities model's data factory.",
   "systems": [
    "fafohive",
    "fafo-core",
    "capabilities-model",
    "postgresql-fabric"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "1,024",
     "label": "dimensions declared on the memory vector column, checked at the boundary"
    }
   ],
   "lede": "One row for meaning, identifiers and project In the memory capability of FAFOHive I wanted one query to search by meaning, match exact identifiers and filter by project, so I kept vectors in PostgreSQL with pgvector, in the same row as the text and metadata they describe. Retrieval, filtering and audit are then one query. Each observation, a decision or fix captured from a coding session, carries an embedding beside a weighted full-text column, provenance fields and token-savings accounting. The weighted full text catches exact identifiers that embeddings blur. design <figure class=\"dv-figure\" aria-label=\"Hybrid search: lexical and dense rankings fused, then reranked\" <div style=\"display: grid; gap: 1.5rem; grid-template-columns: repeat(auto-fit, minmax(min(100%, 170px), 1fr))\" <div <span class=\"eyebrow\" Weighted full text</span <div style=\"display: grid;",
   "quote": "For me pgvector is a decision about where vectors belong.",
   "evidence": [
    "Vector search and ANN indexes: pgvector embeddings in the same PostgreSQL row as text, metadata and provenance, so meaning, exact identifiers and project filters are one query.",
    "Hybrid retrieval: weighted full-text and dense rankings fused and reranked by a cross-encoder, with fusion alone as the fallback when the reranker is saturated.",
    "Type-safe data access: a resolver that reads a vector column's declared dimension from its type modifier, binding 1,024-value embeddings and refusing any other length."
   ],
   "technology_kind": "datastore"
  },
  {
   "url": "https://coreyjames.ai/technologies/policy-as-code-enforcement/",
   "kind": "technology",
   "title": "Policy-as-code enforcement",
   "subtitle": "Policy in my governance platform is enforced by hooks, not remembered by prompts: a lead cannot edit an artifact, work cannot dispatch before its evidence exists, a hook may never report an operation that did not happen.",
   "systems": [
    "agentos"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "~100",
     "label": "hook modules served by one binary"
    },
    {
     "value": "11",
     "label": "lifecycle events where policy runs"
    },
    {
     "value": "63",
     "label": "shell hooks it replaced, ported with tests"
    }
   ],
   "lede": "Rules moved out of the prompt and into the runtime In AgentOS I found that long agent runs fail because the agent is asked to remember the rules along with everything else. I moved the rules out of the agent and into code that runs inside its runtime, in the hook points the agent cannot route around. The coding tools I govern expose lifecycle hooks, before a tool call, after one, at session start, when the agent tries to stop. One Rust binary serves all of them. The diagnosis is in Why long agent runs fail. A publisher writes the hook configuration into each agent environment and checks it byte for byte, so the rules that run are the rules",
   "quote": "I turn an operating procedure into enforcement an autonomous agent cannot ignore, and I phrase each refusal so it teaches the next correct step.",
   "evidence": [
    "Policy-as-code for AI agents: about 100 hook modules across 11 lifecycle events in one Rust binary, ported from 63 shell hooks, enforcing rules inside the agent runtime.",
    "Multi-agent governance: ratified work orders locked to the operator, agents confined to their assigned paths, and refusals that name only a command that exists for that agent.",
    "Configuration integrity: hook configuration published into every agent environment with a byte-for-byte check against the approved copy.",
    "Incident-driven guardrails: a test that wrote into the real database became a source-scanning rule that fails the build on any unapproved database connection."
   ],
   "technology_kind": "discipline"
  },
  {
   "url": "https://coreyjames.ai/technologies/postgresql-bulk-update-engineering/",
   "kind": "technology",
   "title": "PostgreSQL bulk-update engineering",
   "subtitle": "Statement shape, batch width and index cost, each judged by what the database actually does with a write.",
   "systems": [
    "postgresql-fabric",
    "fafo-core",
    "inference-fabric"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "3.4M",
     "label": "items in one write-back run"
    },
    {
     "value": "65,535",
     "label": "bind parameters, the ceiling no batch reaches"
    },
    {
     "value": "~400 GB",
     "label": "of never-scanned vector indexes dropped"
    }
   ],
   "lede": "My research pipeline writes millions of rows back to PostgreSQL through one service, and the shape of each statement decides whether that service keeps up. The work lives in the write path of FAFO Core and Function Forge and serves the Inference Fabric's completion side. Unnest instead of inline values Bulk updates bind each column as one array and unnest the arrays into a row set joined to the target on its key. The parameter count then equals the column count whatever the row count, which keeps every batch under PostgreSQL's bind-parameter limit, and the planner joins directly instead of materialising a derived table. The run that proved it is told in Twenty thousand rows a second. design <figure class=\"dv-figure\"",
   "quote": "Throughput is measured from the database's own tuple and commit counters, never from queue length, because one queue message can be thousands of rows or none.",
   "evidence": [
    "PostgreSQL performance tuning: array-bound unnest updates whose parameter count equals the column count, under the 65,535 bind-parameter limit, from more than 25 s a batch to about 0.3 s.",
    "High-volume database write paths: a 3.4M-item write-back run moved from about 1,350 rows a batch to 3,276 rows, with batch width derived from the payload's own width.",
    "Index cost engineering: about 400 GB of never-scanned vector indexes dropped from the write path, and a missing unique index added after sequential-scan counts pointed to it."
   ],
   "technology_kind": "discipline"
  },
  {
   "url": "https://coreyjames.ai/technologies/postgresql/",
   "kind": "technology",
   "title": "PostgreSQL",
   "subtitle": "PostgreSQL is the source of truth for everything I build: a governance work graph, lease-based claiming designed against its concurrency model, and diagnosis from its own tuple statistics.",
   "systems": [
    "agentos",
    "agent-swarm",
    "helix",
    "fafohive",
    "fafo-core",
    "inference-fabric",
    "capabilities-model",
    "postgresql-fabric"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "546K",
     "label": "lines in the control plane built on it"
    },
    {
     "value": "88",
     "label": "tables in the AgentOS work graph"
    },
    {
     "value": "79",
     "label": "forward-only schema migrations"
    }
   ],
   "lede": "The work graph behind AgentOS In AgentOS the root problem was state held in a model's context, so I put all of it in PostgreSQL, the one source of truth. Every work order, task, piece of evidence, verdict and cost lives in a relational work graph, and the readable views agents see are generated from it and never edited back. Cost attribution and the effort methodology are computed in PL/pgSQL from the same tables. Schema changes are generated and run against a throwaway database before they touch the real one. See Why long agent runs fail. design <figure class=\"dv-figure\" aria-label=\"The work graph in PostgreSQL is the truth; the views agents read are drawn from it, and an edit to a",
   "quote": "I build systems around PostgreSQL as the authority that makes autonomous agents' work recoverable and auditable, and the same habits recur across very different systems.",
   "evidence": [
    "PostgreSQL schema design: a 546K-line control plane over 88 tables and 79 forward-only migrations, with every agent-readable view generated from the database and never edited back.",
    "Concurrent work claiming: lease-based claiming and FOR UPDATE SKIP LOCKED with natural-key writes, so parallel workers never take the same item and a replay adds nothing twice.",
    "Event-driven database design: LISTEN/NOTIFY catalog drift detection with a polling fallback and a hysteresis period before switching back.",
    "Vector data architecture: metadata and lineage in PostgreSQL with vectors kept out of SQL in GPU-addressable shards for high-throughput inference."
   ],
   "technology_kind": "datastore"
  },
  {
   "url": "https://coreyjames.ai/technologies/prometheus/",
   "kind": "technology",
   "title": "Prometheus",
   "subtitle": "Prometheus carries the numbers that decide whether GPUs earn their keep, follows a fleet that changes under it, and pages one operator's phone.",
   "systems": [
    "inference-fabric",
    "fafo-core",
    "auth-and-access-plane",
    "agentos"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "~137",
     "label": "metrics the broker exports of its own"
    },
    {
     "value": "31",
     "label": "panels on the fabric's Grafana dashboard"
    },
    {
     "value": "96.9%",
     "label": "SM utilisation on the larger card in the 163,000-tokens-a-second run"
    },
    {
     "value": "12",
     "label": "scrape jobs across hosts, GPUs and inference nodes"
    }
   ],
   "lede": "Panels for the numbers that decide GPU economics In Inference Fabric generic service health told me nothing about whether the GPUs were earning their keep, so I instrumented the quantities that decide GPU economics: padding, cache reuse and token conservation. The broker exports its own metrics into a Grafana dashboard, and GPU utilisation comes from NVIDIA's DCGM exporter beside the runtime's counters. design <figure class=\"dv-figure\" aria-label=\"What the fabric dashboard tracks\" <div style=\"display: grid; grid-template-columns: repeat(auto-fit, minmax(min(100%, 150px), 1fr)); gap: 8px; margin-top: 0.4rem\" <div style=\"border: 1px solid var(--rule); border-radius: 10px; padding: 8px\" <span class=\"lbl\" style=\"font-size: 0.72rem\" Padding waste</span <div aria-hidden=\"true\" style=\"display: flex; align-items: flex-end; gap: 2px; height: 40px; margin-top: 6px\" <i style=\"flex: 1; height: 6%; border-radius: 2px; background: var(--tone)\" </i <i",
   "quote": "A panel that should read zero is a test; any non-zero difference between tokens received and routed is a defect.",
   "evidence": [
    "Observability and alerting: Prometheus, Grafana and alerting built end to end, about 137 broker metrics on a 31-panel dashboard and 12 scrape jobs across hosts, GPUs and inference nodes.",
    "GPU utilisation monitoring: token-conservation and padding panels beside DCGM exporter data, with 96.9% SM utilisation on the larger card in the 163,000-tokens-a-second run.",
    "Dynamic service discovery: provisioning code writes GPU nodes into Prometheus's file-based service discovery as agents add and drain them, so monitoring follows the fleet."
   ],
   "technology_kind": "platform"
  },
  {
   "url": "https://coreyjames.ai/technologies/prompt-injection-aware-tooling/",
   "kind": "technology",
   "title": "Prompt-injection-aware tooling",
   "subtitle": "Tool descriptions are attack surface. Shell-template injection fixtures are mandatory for the tool kind that needs them, and the discovery tool's description is capped by a test.",
   "systems": [
    "fafohive"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "~500",
     "label": "tool descriptions treated as untrusted text"
    },
    {
     "value": "3",
     "label": "servers whose catalogs are read, never called"
    }
   ],
   "lede": "Tool text treated as untrusted data In FAFOHive I wanted readable guides to every tool across its servers, most of them published by vendors. Asking a model to summarise each tool has a trap in it: a tool's name, description and schema are text written by whoever published the tool, and a model that reads them with any authority can be steered by them. I decided every tool description is untrusted data and built a tool explorer around that. Discovery is read-only. The explorer reads each server's catalog and never calls a tool, so exploring cannot cause a side effect. Official descriptions and AI-written guides are stored and shown separately and never merge, so a reader always knows which one",
   "quote": "I build AI features on the assumption that model inputs can be hostile: the model gets text without trust, and its output is checked against facts it could not forge.",
   "evidence": [
    "Prompt-injection defence: about 500 tool descriptions treated as untrusted data, read from the catalogs of 3 servers and never called during discovery.",
    "LLM output verification: AI-written tool guides keyed to a SHA-256 hash of each tool, in batches rejected whole on one forged identifier, duplicate entry or mismatched hash.",
    "Sandboxed model sessions: audits that start only when I start them, in a locked-down command-line session that can write nothing but its output file."
   ],
   "technology_kind": "discipline"
  },
  {
   "url": "https://coreyjames.ai/technologies/provider-terms-compliance-in-model-routing/",
   "kind": "technology",
   "title": "Provider-terms compliance in model routing",
   "subtitle": "A terms-of-service firewall in the agent runtime decides which traffic may reach which provider, so a subscription session is used as its vendor permits.",
   "systems": [
    "agent-swarm"
   ],
   "technologies": [],
   "stats": [],
   "lede": "How an automatic router breaks terms by accident In Agent Swarm a router picks a model endpoint for every agent request, from my own GPUs or from hosted providers, and some providers' terms forbid automated, unattended back-end use of their models. In an automatic router that rule is easy to break by accident. design <figure class=\"dv-figure\" aria-label=\"A persona's fallback list happens to include an endpoint registered for another purpose, and a background job lands on it\" <span class=\"eyebrow\" One persona's model list, top to bottom · a background job arrives</span <div style=\"display: grid; gap: 6px; margin-top: 0.8rem\" <div style=\"display: grid; grid-template-columns: minmax(0, 1fr) 10rem; gap: 0.8rem; align-items: center\" <div aria-hidden=\"true\" style=\"height: 26px; border-radius: 6px; background: var(--ink-3); opacity: 0.45\" </div <span",
   "quote": "I put compliance inside the mechanism that could violate it, and I check twice where a mistake would be invisible.",
   "evidence": [
    "Model routing with compliance constraints: provider terms enforced in the agent router, separating foreground use for a person from unattended back-end use.",
    "Defence in depth: the terms rule checked at endpoint registration and again on every routing decision, with an explicit no-eligible-endpoint result instead of a guess.",
    "Multi-provider LLM integration: hosted providers presented in the same OpenAI-compatible shape as local GPU models, rate-limited in Redis and self-registering."
   ],
   "technology_kind": "discipline"
  },
  {
   "url": "https://coreyjames.ai/technologies/public-environmental-data-apis/",
   "kind": "technology",
   "title": "Public environmental data APIs",
   "subtitle": "Public weather and environmental data feed a product-shaped MCP server that exposes 21 tools, with a trimmed surface for a vendor agent platform.",
   "systems": [
    "auth-and-access-plane"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "9",
     "label": "public data-service clients behind one server"
    },
    {
     "value": "15",
     "label": "tool classes in the .NET port"
    },
    {
     "value": "2",
     "label": "MCP SDKs the same product was built on"
    }
   ],
   "lede": "Aggregate before answering In the Auth and access plane I built a weather MCP server as a worked example of a product-shaped tool server, and the problem it solves is size. Public weather data is hourly, multi-variable and far larger than an assistant should read, and an assistant asked \"can we pour concrete on Thursday?\" needs a judgment. design <blockquote class=\"dv-quote\" <p I decided the server would aggregate before it answers.</p </blockquote design <figure class=\"dv-figure\" aria-label=\"From hourly data to a judgment\" <div style=\"display: grid; grid-template-columns: 3fr 1.4fr 1fr; gap: 14px; align-items: end; margin-top: 0.8rem\" aria-hidden=\"true\" <div style=\"display: flex; align-items: flex-end; gap: 1px; height: 70px\" <i style=\"flex: 1; height: 50%; border-radius: 1px; background: var(--rule)\" </i <i style=\"flex: 1; height: 95%; border-radius:",
   "quote": "I decided the server would aggregate before it answers.",
   "evidence": [
    "MCP server design: a product-shaped weather server over 9 public data-service clients that aggregates hourly data into daily answers and a construction-weather advisory.",
    "Resilient third-party API integration: each public source with its own cache, retries and timeouts, so a failing service degrades only its part of an answer.",
    "Microsoft Copilot Studio integration: 21 tools for desktop assistants and a trimmed Streamable-HTTP surface for Copilot Studio, the same product built on 2 MCP SDKs with 15 tool classes in .NET."
   ],
   "technology_kind": "platform"
  },
  {
   "url": "https://coreyjames.ai/technologies/pybind11/",
   "kind": "technology",
   "title": "pybind11",
   "subtitle": "pybind11 binds ActiveKV's C++ engine into vLLM and PyTorch; a line-by-line audit proves every remaining Python line is a framework contract.",
   "systems": [
    "activekv"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "67",
     "label": "pybind11 modules expose the C++ engine to the parts of vLLM that call it"
    },
    {
     "value": "866",
     "label": "of 867 places where Python dispatched work became direct native calls"
    },
    {
     "value": "0",
     "label": "lines of my own Python in the release payload"
    }
   ],
   "lede": "From a Python prototype to C++ inside vLLM In ActiveKV the Python version proved the design and was too slow on the per-token path, and it left the product logic as readable source. I moved the whole runtime to C++ inside vLLM, with pybind11 as the boundary, built against PyTorch's ATen. design <figure class=\"dv-figure\" aria-label=\"Parity between the C++ runtime and the Python reference\" <div class=\"dv-two\" <div <span class=\"eyebrow\" Exact-mode parity cells</span <div aria-hidden=\"true\" style=\"display: grid; grid-template-columns: repeat(12, minmax(0, 16px)); gap: 3px; margin-top: 0.7rem\" <i style=\"aspect-ratio: 1; border-radius: 3px; background: var(--tone)\" </i <i style=\"aspect-ratio: 1; border-radius: 3px; background: var(--tone)\" </i <i style=\"aspect-ratio: 1; border-radius: 3px; background: var(--tone)\" </i <i style=\"aspect-ratio: 1; border-radius: 3px; background: var(--tone)\" </i <i style=\"aspect-ratio: 1; border-radius: 3px;",
   "quote": "The language boundary is a contract I minimise and justify line by line.",
   "evidence": [
    "C++ and native ports with parity proof: a Python runtime moved to C++ inside vLLM, 866 of 867 Python dispatch sites made direct native calls, parity cells matched bit for bit.",
    "Python and C++ interoperability with pybind11: 67 binding modules into vLLM and PyTorch, and a line-by-line audit leaving only cited framework contracts in Python.",
    "Release engineering for native extensions: a native launcher that embeds the Python interpreter, and a release of compiled binaries plus a patch with 0 lines of my own Python."
   ],
   "technology_kind": "framework"
  },
  {
   "url": "https://coreyjames.ai/technologies/pyo3/",
   "kind": "technology",
   "title": "PyO3",
   "subtitle": "An earlier in-process Python binding for embeddings, replaced by a separate inference server.",
   "systems": [
    "fafo-core",
    "fafohive"
   ],
   "technologies": [],
   "stats": [],
   "lede": "I use a language bridge where it saves time and remove it when it costs more than it saves, without disturbing the code that depends on it. These are thin wrappers around a third-party Python model; the judgment is in where the boundary sat and when it moved. An embedding model inside a Rust function In FAFO Core and Function Forge the research and memory functions are Rust, and the embedding model they needed was easiest to reach through a Python library. I used PyO3 to bring the model into the Rust function and keep everything else native. The rest of the function stays ordinary Rust on the substrate, queue-driven and controllable like any other. The research steps that consumed",
   "quote": "PyO3 bought speed of delivery; once its cost showed, I moved the model behind a network boundary.",
   "evidence": [
    "Rust and Python interop with PyO3: an embedding model called from async Rust on blocking worker threads, the interpreter lock held only there, returning embedding vectors.",
    "Service boundary design: the GPU embedding model moved out of process to an embedding server over mutual TLS with the internal interface unchanged, so no caller changed."
   ],
   "technology_kind": "framework"
  },
  {
   "url": "https://coreyjames.ai/technologies/python/",
   "kind": "technology",
   "title": "Python",
   "subtitle": "Python is where I prototype and where frameworks demand it: ActiveKV began in Python inside vLLM before the native port, the OAuth server is Python, and the training and evaluation harnesses are Python.",
   "systems": [
    "auth-and-access-plane",
    "fafohive",
    "helix",
    "activekv",
    "capabilities-model",
    "agentos",
    "fafo-core"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "22,000",
     "label": "lines of Python in the OAuth authorization server"
    },
    {
     "value": "11,800",
     "label": "hand-written lines in the X module"
    },
    {
     "value": "45,000",
     "label": "lines of Python that proved ActiveKV before the native port"
    },
    {
     "value": "~1 s",
     "label": "fixed cost per speech request removed by caching voice conditioning"
    }
   ],
   "lede": "I use Python where integration speed and ecosystem matter. An OAuth server for outside assistants In the Auth and access plane I needed commercial AI assistants, including Copilot Studio, to authenticate to my private tool estate, and a FastAPI service was the fastest way to speak OAuth correctly. See The hardening fix that locked everyone out. design <figure class=\"dv-figure\" aria-label=\"Clients that registered themselves pass one human gate before any grant\" <div style=\"display: flex; align-items: center; gap: 1rem; flex-wrap: wrap\" <div style=\"flex: 1; min-width: 140px\" <div style=\"display: flex; flex-wrap: wrap; gap: 4px; margin-top: 0\" aria-hidden=\"true\" <i style=\"width: 16px; height: 16px; border-radius: 3px; background: var(--rule); \" </i <i style=\"width: 16px; height: 16px; border-radius: 3px; background: var(--rule); \" </i <i style=\"width: 16px; height:",
   "quote": "Components that must be long-lived, concurrent and governed move to Rust once the Python prototype has proved the idea.",
   "evidence": [
    "OAuth and identity architecture: a 22,000-line Python authorization server with PKCE, dynamic client registration and a consent screen for outside AI assistants.",
    "API integration in Python: social-platform modules on FastMCP, 11,800 hand-written lines in one, each with its own rate limiter, budget reservations and a durable SQLite ledger.",
    "Prototype-to-native migration: 45,000 lines of Python that proved a vLLM extension, kept unwired as the bit-exact parity reference after the C++ port.",
    "Numerical validation before kernel work: candidate 4-bit weight layouts correlated in Python against the full-precision checkpoint before any kernel was written."
   ],
   "technology_kind": "language"
  },
  {
   "url": "https://coreyjames.ai/technologies/pytorch/",
   "kind": "technology",
   "title": "PyTorch",
   "subtitle": "ActiveKV extends PyTorch's XPU backend and ATen from native code; the capabilities model is a PyTorch fine-tune.",
   "systems": [
    "activekv",
    "capabilities-model"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "22",
     "label": "source files registering native operators in PyTorch's own registry"
    },
    {
     "value": "~596 M",
     "label": "parameters in the open-weight base model"
    },
    {
     "value": "≤ 14 min",
     "label": "per full fine-tune, the shortest about two"
    },
    {
     "value": "17.6 GiB",
     "label": "peak memory on one NVIDIA Blackwell GPU"
    }
   ],
   "lede": "I work with PyTorch from both ends: as a native extension that must be indistinguishable from the code it replaced, and as a training tool where the recipe, the size and the rebuild cost are measured choices. I work below the framework when the framework is in the way. Native operators inside vLLM In ActiveKV a native engine manages a model's key-value cache inside vLLM, which is built on PyTorch, so the engine has to speak PyTorch's tensor model exactly. I built it in C++ against ATen, PyTorch's tensor library, and registered its operators with PyTorch's own operator registry, so vLLM's attention path calls them as first-class operators. When the runtime moved from Python to C++ it had to stay",
   "quote": "Profiles built on framework events are checked against an uninstrumented run before I believe them.",
   "evidence": [
    "PyTorch native extension development: C++ operators on ATen registered in PyTorch's own registry across 22 source files, indistinguishable from the Python version bit for bit.",
    "LLM fine-tuning: a full fine-tune of every parameter of a ~596 M-parameter model in 2 to 14 minutes, peaking at 17.6 GiB on one NVIDIA Blackwell GPU.",
    "GPU profiling methodology: a conclusion built on timing-enabled events retracted once the events were shown to serialise the copy engine they observed."
   ],
   "technology_kind": "framework"
  },
  {
   "url": "https://coreyjames.ai/technologies/ratatui/",
   "kind": "technology",
   "title": "ratatui",
   "subtitle": "A terminal console over my execution substrate's Redis control plane, for watching function services and steering them.",
   "systems": [
    "fafo-core",
    "auth-and-access-plane"
   ],
   "technologies": [],
   "stats": [],
   "lede": "Watching the substrate from a terminal FAFO Core and Function Forge runs functions as services whose state lives in Redis. I wanted to watch and steer them from a terminal without opening a browser, so I had a small Rust console built on ratatui and crossterm. A dashboard view rolls the estate up into totals, and a services view lists every active service with its resources; arrow keys and function keys move between them, and a detail view for one service adds its recent control-plane log lines. design <figure class=\"dv-figure\" aria-label=\"The three views: totals for the estate, one row per active service, and one service with its recent log lines\" <div style=\"display: flex; flex-wrap: wrap; gap: 0.8rem\" <div style=\"flex: 1",
   "quote": "The console has no control path an agent lacks.",
   "evidence": [
    "Terminal UI development in Rust: a ratatui and crossterm console over a Redis control plane, refreshing every active service's state each second.",
    "Operator tooling with least privilege: every console action sent as a confirmed MCP tool call through the same authenticated gate an agent uses."
   ],
   "technology_kind": "framework"
  },
  {
   "url": "https://coreyjames.ai/technologies/react/",
   "kind": "technology",
   "title": "React",
   "subtitle": "React builds the Mattermost plugins, the Teams work tab and the meeting-stage app for Helix.",
   "systems": [
    "helix",
    "auth-and-access-plane"
   ],
   "technologies": [],
   "stats": [],
   "lede": "In Helix I wanted people, and the AI colleague they work with, to stay inside the platforms they already use. I build front ends as integration surfaces inside other people's platforms: small, native-looking and backed by a server-side source of truth. Plugins inside the collaboration shell The Control Center, Helix's multi-model collaboration shell, runs on an unmodified Mattermost server. I extend it only through its supported plugin model: everything Helix adds to its interface is a Mattermost webapp plugin in React and JSX, and the plugins are thin. design <figure class=\"dv-figure\" aria-label=\"A thin plugin layer over the control plane that holds the state\" <div style=\"display: flex; gap: 3px; height: 26px; margin-top: 0.2rem; font-size: 0.7rem; font-weight: 600; line-height: 1.1\" aria-hidden=\"true\" <span",
   "quote": "Where a vendor feature has no control an agent can use, I build a surface I control.",
   "evidence": [
    "Microsoft Teams app development: a Fluent UI work tab with Teams single sign-on, and a meeting-stage app an AI agent drives with each action bound to tenant, employee and meeting.",
    "Mattermost plugin development: React webapp plugins for a multi-model collaboration shell, kept thin over server-side state in Rust and PostgreSQL."
   ],
   "technology_kind": "framework"
  },
  {
   "url": "https://coreyjames.ai/technologies/real-time-audio-pipeline-engineering/",
   "kind": "technology",
   "title": "Real-time audio pipeline engineering",
   "subtitle": "PCM framing, resampling, echo-cancellation reference, pacing and drop-on-reconnect: the audio path from a desk microphone or a Teams call to my own speech models.",
   "systems": [
    "helix"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "91,643",
     "label": "call buffers moved in a 30-minute soak"
    },
    {
     "value": "50.001/s",
     "label": "buffer rate held across that soak"
    },
    {
     "value": "0",
     "label": "receive stalls in the same run"
    },
    {
     "value": "30 ms",
     "label": "denoiser latency gate at the 95th percentile"
    }
   ],
   "lede": "One audio seam for a desk and a Teams call In Helix I wanted one voice engine to work on a desk microphone and inside a Teams call without the conversation logic knowing which. I gave the Rust engine one sealed audio seam: an abstract source and sink with one frame contract, so a new audio endpoint is an implementation and the engine does not change. The same turn-taking and interruption behaviour runs in both. design <figure class=\"dv-figure\" aria-label=\"The frame contract at the audio seam: 16 kHz in, 24 kHz out, in 20 ms frames\" <div style=\"display: grid; grid-template-columns: 7rem minmax(0, 1fr); gap: 0.6rem 0.9rem; align-items: center; font-size: 0.82rem\" <span in · 16 kHz</span <div aria-hidden=\"true\" style=\"display: flex; gap: 3px\"",
   "quote": "An agent acting on words nobody said is worse than one that asks again.",
   "evidence": [
    "Real-time voice AI: one Rust voice engine behind a sealed audio seam of 20 ms frames, 16 kHz in and 24 kHz out, on a desk microphone and inside Teams calls.",
    "Microsoft Teams real-time media: a .NET media bridge and Rust host on one WebSocket per call, a 30-minute soak moving 91,643 buffers at 50.001 per second with 0 receive stalls.",
    "Audio signal processing: echo cancellation, a denoiser under a 30 ms 95th-percentile latency gate, an operator voiceprint filter and voice-activity detection ahead of recognition.",
    "Latency engineering: question-to-first-sound cut from about 2.1 s to about 0.9 s with streaming synthesis and cached voice conditioning."
   ],
   "technology_kind": "discipline"
  },
  {
   "url": "https://coreyjames.ai/technologies/reddit/",
   "kind": "technology",
   "title": "Reddit",
   "subtitle": "An in-house Reddit integration through my own browser session, with duplicate-safe receipts and a read-back after every change.",
   "systems": [
    "fafohive"
   ],
   "technologies": [],
   "stats": [],
   "lede": "Acting through the operator's own browser FAFOHive needed agents to take part in Reddit threads, and my estate has no API route to the site. I decided the module would act through the operator's own browser session and leave every credential in that browser, where the operator already trusts it. The provider service talks over a private local socket to a native-messaging host, and the host hands each request to a small browser extension that sends the same requests the site sends from the signed-in tab. The service never sees a cookie, opens no automation browser and clicks nothing, so a layout change cannot break it. design <blockquote class=\"dv-quote\" <p When a platform offers no sanctioned API path, I narrow",
   "quote": "When a platform offers no sanctioned API path, I narrow the surface until every action can be checked against the page itself.",
   "evidence": [
    "Browser-session integration without credentials: a module acting through the operator's signed-in browser over native messaging, never seeing a cookie or automating the page.",
    "Exactly-once delivery and crash recovery: idempotency keys over the full input, an exact read-back after every change, and an unconfirmed send settled by reading, never posted twice."
   ],
   "technology_kind": "platform"
  },
  {
   "url": "https://coreyjames.ai/technologies/redis/",
   "kind": "technology",
   "title": "Redis",
   "subtitle": "Redis Streams carry my execution substrate's command bus with Lua-atomic job promotion, the agent runtime's messaging, and the write-behind queue. Topology is explicit and documented.",
   "systems": [
    "fafo-core",
    "agent-swarm",
    "agentos",
    "fafohive",
    "auth-and-access-plane",
    "inference-fabric",
    "postgresql-fabric"
   ],
   "technologies": [],
   "stats": [],
   "lede": "A control backbone for FAFO Core FAFO Core and Function Forge needed a backbone for job state and real-time control that could take bursts, and I put it on Redis. Each function has pending, processing and dead-letter queues and per-job state keys, and multi-step state changes run as server-side Lua, so each is atomic in one round trip. Control commands travel on a Redis stream read by a consumer group, with a separate high-priority stream so a pause or drain never waits behind bulk traffic. design <figure class=\"dv-figure\" aria-label=\"One function's three queues, with Lua moving a job between them atomically\" <div style=\"display: grid; grid-template-columns: 7.5rem minmax(0, 1fr); gap: 0.6rem 0.9rem; align-items: center; font-size: 0.84rem\" <span Pending</span <div class=\"dv-pages\" aria-hidden=\"true\" <span",
   "quote": "I treat Redis as a component with chosen semantics.",
   "evidence": [
    "Redis Streams and queue design: a command bus on consumer groups with a separate high-priority stream so pause and drain never wait behind bulk traffic, and job promotion as atomic Lua.",
    "Reliable message delivery and crash recovery: agent inboxes on consumer groups that reclaim unacknowledged messages after a fence and set poison messages aside.",
    "Data store failure-mode design: Redis instances split by role, caches that evict and a write-behind queue with eviction off that refuses work rather than drop a write."
   ],
   "technology_kind": "datastore"
  },
  {
   "url": "https://coreyjames.ai/technologies/reranker-model/",
   "kind": "technology",
   "title": "Reranker model",
   "subtitle": "A cross-encoder reranker sits behind my hybrid retrieval, on a seam that tells load from breakage.",
   "systems": [
    "fafohive"
   ],
   "technologies": [],
   "stats": [],
   "lede": "The reranker is the published model, used without training or tuning; the engineering is in where it sits and how it fails. The rescoring step in every search FAFOHive serves search to many agents at once, and the most expensive step in a search is the cross-encoder that reorders the candidates. the reranker model is that cross-encoder: it rescores the merged results of lexical and dense retrieval for code, reference and observation search. It runs as a local HTTP service. The call stays in process, with no queue hop between search and rerank, so its latency budget is predictable. The retrieval design is on Hybrid retrieval. design <figure class=\"dv-figure\" aria-label=\"Where the reranker sits in one search\" <div style=\"position: relative\" <div",
   "quote": "When the reranker saturates, search quality degrades and search availability does not.",
   "evidence": [
    "Cross-encoder reranking: a published reranker rescoring merged lexical and dense results for code, reference and observation search, called in process with no queue hop.",
    "Capacity engineering for model endpoints: the reranker client wrapped in a bounded-endpoint primitive that sorts every failure into busy or broken, with separate counters."
   ],
   "technology_kind": "model"
  },
  {
   "url": "https://coreyjames.ai/technologies/research-data-forensics/",
   "kind": "technology",
   "title": "Research data forensics",
   "subtitle": "I rebuild and prove a research dataset before I trust it.",
   "systems": [
    "capabilities-model"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "~12,000",
     "label": "golden examples rebuilt from two sources"
    },
    {
     "value": "13 GB",
     "label": "SQLite backup, the second witness"
    }
   ],
   "lede": "Two incomplete witnesses Research and inventions mentions the curated corpus of golden examples from my first distillation pipeline. When I came back to it, the corpus was split between a PostgreSQL database that had kept changing and a SQLite backup. Neither was complete, and no notes said how its cluster centroids had been computed. I decided to rebuild it from both sources and reproduce its derived data exactly before trusting any of it. I directed the recovery in phases, each closed by a written report. I treated the database and the backup as two independent witnesses: they were compared entry by entry, every gap in one was explained from the other, and each filled the other's gaps. design <figure class=\"dv-figure\"",
   "quote": "Two views of the same data that disagree mislead every model trained on them.",
   "evidence": [
    "Data recovery and forensics: a corpus of about 12,000 golden examples rebuilt from a changing PostgreSQL database and a 13 GB SQLite backup, compared entry by entry.",
    "Reproducible data pipelines: the centroid computation reverse-engineered from the stored centroids, so recovered data is derived the same way as the original.",
    "ML data quality: alignment measured between passage medoids and mean question-and-answer embeddings, with phantom clusters that had no source text set aside."
   ],
   "technology_kind": "discipline"
  },
  {
   "url": "https://coreyjames.ai/technologies/reversible-infrastructure-mutation/",
   "kind": "technology",
   "title": "Reversible infrastructure mutation",
   "subtitle": "Edits that touch several services happen in one rollback-protected transaction, and every create has a symmetric delete. The function generator is the worked example.",
   "systems": [
    "fafo-core"
   ],
   "technologies": [],
   "stats": [],
   "lede": "One operation across five parts FAFO Core and Function Forge lets an agent add a function to a working multi-service estate, and I wanted every such change to be undoable exactly. Creating a function adds a crate and edits four other parts of the estate in one operation. design <figure class=\"dv-figure\" aria-label=\"One create edits five parts; a failure at the fourth rolls the first three back\" <span class=\"eyebrow\" Applying one create</span <div style=\"display: flex; gap: 4px; margin-top: 0.6rem\" <div style=\"flex: 1; min-width: 0\" <div aria-hidden=\"true\" style=\"height: 22px; border-radius: 4px; background: var(--tone); color: var(--on-navy); font-size: 0.72rem; font-weight: 700; display: flex; align-items: center; justify-content: center\" 1</div </div <div style=\"flex: 1; min-width: 0\" <div aria-hidden=\"true\" style=\"height: 22px; border-radius: 4px; background: var(--tone); color: var(--on-navy);",
   "quote": "I design changes to a working system so they can be undone exactly, and I put the human decision on the one step where undo stops being free.",
   "evidence": [
    "Reversible infrastructure changes: a function generator whose edits across five parts of a multi-service estate run through one atomic file layer with rollback.",
    "Code generation with exact undo: every generated edit anchored at a landmark so delete reverses it exactly, and regeneration over a developer zone refused unless forced.",
    "Human-in-the-loop operations: build and restart separated, so every automated step can be repeated or undone and the restart is the one human step."
   ],
   "technology_kind": "discipline"
  },
  {
   "url": "https://coreyjames.ai/technologies/rmcp-rust-mcp-sdk/",
   "kind": "technology",
   "title": "rmcp (Rust MCP SDK)",
   "subtitle": "The Rust MCP SDK underlies my memory gateway and the meeting action server.",
   "systems": [
    "fafohive",
    "helix"
   ],
   "technologies": [],
   "stats": [],
   "lede": "A Rust MCP server on the SDK's types FAFOHive needed an MCP server in Rust, and I built it on rmcp, the Rust MCP SDK, for its protocol types and server traits. The tool surface, dispatch and security are mine. The server registers three families of tools behind one list. design <figure class=\"dv-figure\" aria-label=\"One tool list as an agent sees it, each row coloured by the dispatch path behind it\" <div style=\"display: grid; grid-template-columns: minmax(0, 1fr) minmax(0, 1fr); gap: 1.4rem; align-items: start\" <div style=\"border-radius: 10px; border: 1px solid var(--rule); background: var(--bg); padding: 0.6rem 0.8rem\" aria-hidden=\"true\" <i style=\"display: block; height: 9px; width: 78%; border-radius: 4px; margin-top: 4px; background: var(--green)\" </i <i style=\"display: block; height: 9px; width: 79%; border-radius: 4px; margin-top: 4px;",
   "quote": "I use a vendor SDK for what it does well and replace the part that breaks under real operation, once, in the server.",
   "evidence": [
    "MCP server design: a Rust MCP server on rmcp presenting native, hosted and provider tools in one list, each family under its own trust model.",
    "Zero-trust architecture: a stateless per-request transport over Axum with fail-closed bearer-token introspection, replacing a session transport that broke on restart, with per-tool timeouts up to 120 seconds."
   ],
   "technology_kind": "framework"
  },
  {
   "url": "https://coreyjames.ai/technologies/runpod/",
   "kind": "technology",
   "title": "RunPod",
   "subtitle": "Rented cloud GPU spot capacity is one provisioning target behind my substrate's fail-closed daily budget; always available, never uncapped.",
   "systems": [
    "fafo-core",
    "inference-fabric",
    "fafohive"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "0",
     "label": "dollar cap on a day with no budget set; paid provisioning is refused"
    },
    {
     "value": "1/100 ¢",
     "label": "resolution of spend, counted per second"
    },
    {
     "value": "5 min",
     "label": "price cache, which can list cheaper GPU types under a ceiling"
    }
   ],
   "lede": "Rented GPUs behind a compute trait FAFO Core and Function Forge needed to burst onto rented GPUs. RunPod is one implementation of a provider-neutral compute trait, next to local Docker and remote Docker on LAN hosts over mutual TLS, so location is configuration and one function binary runs in any of the three. design <figure class=\"dv-figure\" aria-label=\"The same runtime binary injected into a generic image on each of three compute targets\" <div style=\"display: grid; grid-template-columns: repeat(auto-fit, minmax(150px, 1fr)); gap: 8px\" <div class=\"gpu\" style=\"padding: 10px 12px\" <span class=\"eyebrow\" Local Docker</span <div class=\"die\" style=\"grid-template-columns: repeat(6, 1fr)\" <b </b <b </b <b </b <b </b <b </b <b style=\"background: var(--tone); outline: 2px solid var(--on-navy)\" </b <b class=\"off\" </b <b class=\"off\" </b <b class=\"off\"",
   "quote": "I let agents drive cloud GPU capacity without letting them spend money nobody approved, by putting the budget in the critical path.",
   "evidence": [
    "Cloud GPU provisioning with cost controls: rented spot GPUs behind a provider-neutral compute trait and a fail-closed daily cap only a person sets, with a cap of 0 on a day with no budget.",
    "Cost attribution for AI work: spend counted per second to 1/100 of a cent, in Redis first and PostgreSQL for durability, with each container reporting its final cost.",
    "Inference serving architecture: TensorRT-LLM consumer nodes on interruptible spot GPUs joining the token-aware broker over outbound connections only, an engine without declared limits refused.",
    "NVIDIA Blackwell development: datacentre Blackwell parts reached through the same provisioning path with an engine tier, SM 100 kernels and a widened hardware check."
   ],
   "technology_kind": "platform"
  },
  {
   "url": "https://coreyjames.ai/technologies/rust/",
   "kind": "technology",
   "title": "Rust",
   "subtitle": "Rust is my systems language: about a million and a half lines across the governance platform, the agent runtime, the collaboration shell, the memory gateway, the execution substrate and the inference pipeline.",
   "systems": [
    "agentos",
    "agent-swarm",
    "helix",
    "fafohive",
    "fafo-core",
    "inference-fabric",
    "capabilities-model"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "~546,000",
     "label": "lines of Rust in AgentOS, across nineteen crates"
    },
    {
     "value": "121",
     "label": "unsafe blocks in the capabilities model, all in one FFI module"
    },
    {
     "value": "21",
     "label": "domain modules split from two 40,000-line hook files"
    },
    {
     "value": "12",
     "label": "steps every Agent Swarm tool call passes, in a frozen order"
    }
   ],
   "lede": "Policy as compiled code AgentOS had to make AI agents follow rules they could not talk their way around, so I put the rules in compiled code. The database layer and the hook binary are around 200,000 lines each. The hook binary runs under the coding agents' own command-line tools and turns policy into refusals. A refusal is a typed value that can only name a command the system sanctions, so the compiler stops an agent from ever being told to run a command that does not exist. design <figure class=\"dv-figure\" aria-label=\"The set of commands a refusal can name, and one it cannot\" <div style=\"display: flex; align-items: center; gap: 1.2rem; flex-wrap: wrap; margin-top: 0.4rem\" aria-hidden=\"true\" <div style=\"flex: 1; min-width: 200px;",
   "quote": "I put invariants in types wherever the compiler can enforce them.",
   "evidence": [
    "Rust systems engineering: about 546,000 lines of Rust in a governance control plane, where a refusal is a typed value that can only name a command the system sanctions.",
    "Unsafe code containment and FFI: 121 unsafe blocks confined to one FFI module over CUDA, with layout tests that fail the build if the Rust and C views disagree.",
    "Concurrency design in Rust: a synchronous single-owner hot loop for a 24,000-line token-aware broker, and async Tokio for the voice engine and the transports that wait on I/O.",
    "Build-enforced invariants: link-time registration that fails the build for an unwired function, and 12 frozen pipeline steps on every Agent Swarm tool call."
   ],
   "technology_kind": "language"
  },
  {
   "url": "https://coreyjames.ai/technologies/schema-agnostic-data-access-and-sql-injection-defence/",
   "kind": "technology",
   "title": "Schema-agnostic data access and SQL-injection defence",
   "subtitle": "Database access in generated code goes through a schema resolver that validates every identifier; raw pools are excluded from the sandbox; SQL is never assembled from strings an agent wrote.",
   "systems": [
    "fafo-core"
   ],
   "technologies": [],
   "stats": [],
   "lede": "Shapes read from the catalogs FAFO Core and Function Forge lets functions, including ones written by AI agents, run against any registered data source, and I wanted that with no table name in code and no route to SQL injection. The substrate reads the shape of a view or table from PostgreSQL's system catalogs at runtime and caches it, including vector dimensions from each column's type modifier and array element types, so a function is written against a contract. JSON values are checked against the discovered column types, and binding follows the column type. design <figure class=\"dv-figure\" aria-label=\"Column shapes read from the catalogs, and values that fit them or do not\" <div style=\"display: flex; gap: 10px\" class=\"lbl\" <span style=\"flex: 4\"",
   "quote": "I treat SQL injection and schema coupling as API-design problems and solve them by limiting what code can reach.",
   "evidence": [
    "SQL injection defence: one entry point that pattern-checks and quotes every identifier, every value a bound parameter, and raw connection pools kept out of function code.",
    "Schema-agnostic data access: view and table shapes read from PostgreSQL's system catalogs at runtime, with binding by actual column type including vector dimensions.",
    "Sandboxing AI-written code: a capability-bounded context where reads go through the schema resolver and writes only through the governed write path."
   ],
   "technology_kind": "discipline"
  },
  {
   "url": "https://coreyjames.ai/technologies/schema-and-migration-discipline/",
   "kind": "technology",
   "title": "Schema and migration discipline",
   "subtitle": "Forward-only migrations, schema contracts and a baseline frozen as immutable. Schema is a contract, and I treat it that way.",
   "systems": [
    "agentos",
    "postgresql-fabric"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "79",
     "label": "forward-only migrations"
    },
    {
     "value": "88",
     "label": "tables in the work graph"
    },
    {
     "value": "33",
     "label": "schema contracts"
    }
   ],
   "lede": "Forward-only, never edited AgentOS keeps the state of every work order in its database, so the schema is the law of the system, and I put it under strict discipline. The PostgreSQL work graph is built by forward-only migrations, immutable once applied, so the schema history is also the history of the system's rules. design <figure class=\"dv-figure\" aria-label=\"An applied migration is never edited; a correction is appended after it\" <div style=\"display: grid; gap: 6px\" <div style=\"display: grid; grid-template-columns: minmax(0, 1fr) 11rem; gap: 0.8rem; align-items: center\" <i aria-hidden=\"true\" style=\"display: block; height: 14px; border-radius: 4px; background: var(--navy)\" </i <span class=\"lbl\" baseline · frozen</span </div <i aria-hidden=\"true\" style=\"display: block; height: 2px; background: var(--tone); margin: 2px 0\" </i <div style=\"display: grid; grid-template-columns: minmax(0, 1fr)",
   "quote": "I run schema change on a governance system the way I would on a regulated database: immutable history, compiled changes, isolated qualification and a backup before every step.",
   "evidence": [
    "Database schema migration discipline: 79 forward-only migrations over 88 tables and 33 schema contracts, a frozen baseline and corrections only as new migrations.",
    "Workflow change management: declarative specifications compiled into deterministic bundles and qualified on an isolated PostgreSQL instance before the real database.",
    "Operational safety for databases: a backup before every migration or invasive operation, and probes against a canonical schema snapshot after each change."
   ],
   "technology_kind": "discipline"
  },
  {
   "url": "https://coreyjames.ai/technologies/schema-driven-build-time-code-generation/",
   "kind": "technology",
   "title": "Schema-driven build-time code generation",
   "subtitle": "YAML tool schemas compile into dispatch at build time in my MCP gateway and the execution substrate, so a tool cannot be half-wired.",
   "systems": [
    "fafo-core",
    "fafohive"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "18",
     "label": "tool surfaces declared in YAML"
    },
    {
     "value": "~180",
     "label": "actions across those surfaces"
    },
    {
     "value": "8",
     "label": "sections in every API connectivity profile"
    }
   ],
   "lede": "Tools added by writing files FAFO Core and Function Forge has a tool surface that grows constantly, and I decided nobody would hand-edit dispatch code to add a tool. Declarations live in YAML and the dispatch code is generated, so a new tool is a data change. The model-facing MCP gateway compiles YAML at build time, and input schemas come from the same metadata that drives routing, so they cannot drift from the implementation. The control plane compiles an auto-registration file into its dependency list and an extern-crate macro, and each function crate registers its execution handler and control target at link time. That is how Function Forge adds a tool by writing files. The generator writes the gateway's definitions",
   "quote": "I move integration work out of hand-written code into declarations the build compiles and checks, because that keeps a fast-growing tool estate consistent.",
   "evidence": [
    "Build-time code generation in Rust: YAML tool declarations compiled into modules, a routing table and JSON Schema by build scripts and procedural macros, registered at link time.",
    "MCP server design: 18 tool surfaces with about 180 actions declared in YAML and generated, so a tool cannot be half-wired.",
    "Tool synthesis and governed API integration: each external API described by an 8-section connectivity profile and compiled into one generic runtime built once."
   ],
   "technology_kind": "discipline"
  },
  {
   "url": "https://coreyjames.ai/technologies/site-reliability-engineering/",
   "kind": "technology",
   "title": "Site reliability engineering",
   "subtitle": "A declared systemd fleet, tunnelled ingress, a documented Redis topology and written runbooks keep my estate recoverable.",
   "systems": [
    "auth-and-access-plane",
    "agentos"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "8",
     "label": "written runbooks, from startup to performance degradation"
    },
    {
     "value": "1 day",
     "label": "to roll back the registration lock that broke every client"
    },
    {
     "value": "0",
     "label": "open inbound ports"
    }
   ],
   "lede": "One declared fleet Auth and access plane holds the operations layer for my whole estate. As its only operator, I need the estate to start, fail and recover the same way every time, so the fleet is declared and versioned and startup order is a property of configuration. A few dozen services run under one systemd stack target. PartOf cascades carry a dependency's restart to its dependants, drop-ins make data-store clients wait for the network, and timers run routine work such as container cleanup. Unit files and a readable inventory are versioned with the code, so the fleet is rebuilt from source. design <figure class=\"dv-figure\" aria-label=\"Startup and restart order declared in configuration: network, then data-store clients, then their dependants, and",
   "quote": "I reverse my own change when the evidence calls for it.",
   "evidence": [
    "Site reliability engineering: a declared systemd fleet of a few dozen services under one stack target, with restart cascades and start order versioned with the code.",
    "Incident response and runbooks: 8 written runbooks with thresholds, a severity model and escalation paths, and a registration lock that broke every client rolled back within 1 day.",
    "Observability and alerting: Prometheus with file-based discovery of GPU nodes, Grafana dashboards and Alertmanager routing by severity to SMS paging.",
    "Zero-trust and zero-inbound networking: public surfaces reached only through outbound tunnels and a private mesh, with 0 open inbound ports."
   ],
   "technology_kind": "discipline"
  },
  {
   "url": "https://coreyjames.ai/technologies/speech-recognition-model/",
   "kind": "technology",
   "title": "Speech recognition model",
   "subtitle": "An open speech-recognition model is the recogniser in my voice engine, integrated rather than modified.",
   "systems": [
    "helix"
   ],
   "technologies": [],
   "stats": [],
   "lede": "Recognition on my own hardware Helix holds spoken conversations in a room or on a Microsoft Teams call, and I wanted the speech it hears recognised on my own hardware. the speech recognition model is the recognition model; the engineering is how the voice engine uses it, and above all what it does with an uncertain result. the speech recognition model is an open model served through the open-source its C++ runtime; the integration, the confidence policy and the deployment are mine. The engine's transcriber is an interface with two implementations: the speech recognition model in process through its C++ runtime, and a client for a the speech recognition model server on a GPU host that takes WAV audio and",
   "quote": "A digital employee that answers words nobody said is worse than one that stays quiet.",
   "evidence": [
    "Speech recognition pipelines: an open recogniser behind a transcriber interface, in process or on a GPU server, with the two deployments swapping without touching conversation logic.",
    "Hallucination control in speech recognition: every segment carries a confidence measure, segments under the threshold are dropped, and an empty turn replaces invented text.",
    "Real-time voice AI on local GPUs: recognition on a Blackwell GPU beside neural speech synthesis in the Teams configuration, so a call's audio stays on my hardware."
   ],
   "technology_kind": "model"
  },
  {
   "url": "https://coreyjames.ai/technologies/speech-synthesis-model/",
   "kind": "technology",
   "title": "Speech synthesis model",
   "subtitle": "The neural speech model that gives Helix its voice in Teams calls, a local room and produced narration.",
   "systems": [
    "helix"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "776 ms",
     "label": "to first audio in the first Teams call, synthesis sharing a GPU host"
    },
    {
     "value": "2",
     "label": "speech backends behind one interface, settled by a bake-off"
    },
    {
     "value": "~78%",
     "label": "of the slow turn spent in synthesis while it shared the host"
    }
   ],
   "lede": "A voice server behind a fixed seam Helix speaks in Teams calls and in a local room, and I wanted the voice to run on my own GPUs with no hosted speech service in the loop. Behind one interface the voice engine can use an 82-million-parameter open voice model in process through ONNX Runtime, and the speech synthesis model as a separate GPU service. I ran a bake-off between them, the speech synthesis model won, and I sealed it so later work could not drift the voice. the speech synthesis model is a third-party open model used as published. I wrapped it in a FastAPI streaming server in a GPU container, and the engine treats it as a remote audio",
   "quote": "When synthesis dominated a turn on a shared host, I fixed placement and kept the model.",
   "evidence": [
    "Speech synthesis pipelines: an open voice model wrapped in a streaming server behind a fixed seam, chosen over a second backend by a bake-off.",
    "Latency engineering for voice AI: 776 ms to first audio in the first Teams call, and synthesis that took ~78% of a slow turn moved to a dedicated GPU host.",
    "Performance diagnosis: a flat first-audio curve across clause lengths read as fixed server overhead and fixed by streaming rather than a faster model."
   ],
   "technology_kind": "model"
  },
  {
   "url": "https://coreyjames.ai/technologies/sql/",
   "kind": "technology",
   "title": "SQL",
   "subtitle": "SQL is how I query the stores everything else projects from: work graphs, tuple statistics, retrieval tables, cost ledgers.",
   "systems": [
    "agentos",
    "agent-swarm",
    "fafo-core",
    "helix",
    "postgresql-fabric"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "88",
     "label": "tables in the AgentOS schema, from 79 forward-only migrations"
    },
    {
     "value": "13,000",
     "label": "lines of SQL in that schema"
    },
    {
     "value": "178",
     "label": "tables in Helix's collaboration control store"
    },
    {
     "value": "29",
     "label": "columns in one presence-aware upsert"
    }
   ],
   "lede": "I use SQL to design state, contracts and correctness under concurrency, from a governance state machine to an agent runtime's event writer. The databases are PostgreSQL. Helix keeps the durable state of its collaboration shell in its own PostgreSQL control store, grown alongside the shell's features through numbered migrations. A state machine kept as data AgentOS runs a multi-agent state machine, and I chose to model it relationally, in forward-only migrations. A generic registry sits underneath and the domain sits on top. design <figure class=\"dv-figure\" aria-label=\"Domain tables over a generic registry of objects, kinds, typed edges and transitions\" <span class=\"eyebrow\" The domain</span <div style=\"display: flex; gap: 3px; height: 16px; margin-top: 0.5rem; font-size: 0.7rem; font-weight: 600; line-height: 1.1\" aria-hidden=\"true\" <span style=\"flex:",
   "quote": "In a performance diagnosis, the database's tuple statistics are the ground truth.",
   "evidence": [
    "Relational state-machine design: a multi-agent workflow modelled as data in 88 tables from 79 forward-only migrations, a generic registry under the domain tables.",
    "PostgreSQL concurrency design: single-statement writes under load, including a 29-column presence-aware upsert and conflict-aware launch reservations where one of two wins.",
    "In-database metric logic: PL/pgSQL functions computing a reported labour measure, with the old and new formulas kept side by side for comparison.",
    "PostgreSQL performance tuning: the database's tuple statistics taken as the ground truth about committed work, the habit behind 196 deadlocks to zero."
   ],
   "technology_kind": "language"
  },
  {
   "url": "https://coreyjames.ai/technologies/sqlite/",
   "kind": "technology",
   "title": "SQLite",
   "subtitle": "SQLite gives each of FAFOHive's social and media modules durable, transactional state that one process owns.",
   "systems": [
    "fafohive"
   ],
   "technologies": [],
   "stats": [],
   "lede": "One database per social module FAFOHive's in-house social modules each need durable, transactional state owned by one process, and I gave each its own SQLite database. Where one process owns the state, most concurrency turns into ordinary transactions. The X module keeps a work queue in SQLite and claims jobs inside BEGIN IMMEDIATE transactions, which take the write lock up front, so two workers never claim the same job after a scheduler restart. The Facebook module keeps an inventory of every object it creates, which gives cleanup and reconciliation an exact list. The Reddit module stores a receipt for every change and an archive of every response it reads, so a repeated request with the same idempotency key returns the",
   "quote": "I pick the smallest storage that gives a component its guarantee, and I design around the moment between sent and confirmed.",
   "evidence": [
    "Embedded database design with SQLite: one database per process-owned module, so work-queue claims, object inventories and idempotent receipts are ordinary transactions.",
    "Exactly-once delivery and crash recovery: render-job identity written before sending, and an explicit outcome-unknown state settled by reading the renderer at startup, never resubmitted."
   ],
   "technology_kind": "datastore"
  },
  {
   "url": "https://coreyjames.ai/technologies/sqlx/",
   "kind": "technology",
   "title": "sqlx",
   "subtitle": "sqlx carries my Rust services' PostgreSQL access; where no table is known at compile time, I check against the schema itself instead.",
   "systems": [
    "fafo-core",
    "helix",
    "agent-swarm"
   ],
   "technologies": [],
   "stats": [],
   "lede": "Runtime queries checked against the catalog FAFO Core and Function Forge has a database layer where no table is known at compile time, so I built it on sqlx's runtime query API. Every operation takes a view or table name as a string and reads its shape from PostgreSQL's system catalogs, cached with vector dimensions and array element types. See Tools that build tools, under governance. design <figure class=\"dv-figure\" aria-label=\"Where the checks run: at compile time on the usual path, at runtime against the schema on mine\" <span class=\"eyebrow\" The usual path</span <div style=\"display: flex; gap: 3px; height: 24px; margin-top: 0.8rem; font-size: 0.7rem; font-weight: 600; line-height: 1.1\" aria-hidden=\"true\" <span style=\"flex: 2; min-width: 4px; border-radius: 4px; background: var(--ink-3); color: var(--on-navy); display:",
   "quote": "I know the trade-offs inside a Rust database toolkit well enough to take the runtime path on purpose and rebuild the safety it gives up.",
   "evidence": [
    "Rust database engineering with sqlx: a runtime query layer that reads each table's shape from PostgreSQL's catalogs and binds every value by its column's type, pgvector included.",
    "SQL injection prevention by design: identifiers through a checking resolver and quoting, values only as bound parameters, and raw pools kept from generated code.",
    "Data access architecture: one store crate owning all PostgreSQL access for a collaboration shell, with its schema evolved through numbered migrations."
   ],
   "technology_kind": "framework"
  },
  {
   "url": "https://coreyjames.ai/technologies/state-machine-design-for-multi-agent-workflows/",
   "kind": "technology",
   "title": "State-machine design for multi-agent workflows",
   "subtitle": "Work-order lifecycles, stand-down and resume, and transition compilation: the governance platform is state machines all the way down.",
   "systems": [
    "agentos"
   ],
   "technologies": [],
   "stats": [],
   "lede": "The state machine lives in data AgentOS is a state machine for multi-agent work, and I decided the state machine would live in data where agents cannot rewrite it. A PostgreSQL registry holds objects with kinds, typed edges between them, and a stored transition for every change of state. Work orders, tasks, evidence and verdicts are all instances of that model. Where a piece of work stands is in the graph, and the documents agents read are generated from it. Because the machine is data, it can be queried, audited and changed under migration discipline. design <figure class=\"dv-figure\" aria-label=\"The registry in PostgreSQL and the documents generated from it for agents, with no write path back\" <div style=\"display: grid; grid-template-columns: 11rem",
   "quote": "A system that cannot tell stopped from done eventually closes unfinished work.",
   "evidence": [
    "Control-plane and state-machine architecture: a multi-agent workflow kept as data in a PostgreSQL registry of typed objects, edges and stored transitions that agents cannot rewrite.",
    "Crash recovery by replay: every pending step maps to exactly one next step and is consumed only by its receipt, so resuming after a crash is a replay of the graph.",
    "Formal checks of workflow design: workflow changes compiled and qualified on an isolated database, and a pure walker that found real dead-end gaps in the platform's own state graph."
   ],
   "technology_kind": "discipline"
  },
  {
   "url": "https://coreyjames.ai/technologies/static-analysis-as-tests/",
   "kind": "technology",
   "title": "Static analysis as tests",
   "subtitle": "Static checks run as tests in my governance platform: a carve gate on imports, a check that no hook can surface a non-operation.",
   "systems": [
    "agentos",
    "agent-swarm",
    "capabilities-model"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "41,990",
     "label": "tokens of tool schemas replaced by one description"
    },
    {
     "value": "44",
     "label": "tools across three servers behind that description"
    },
    {
     "value": "520",
     "label": "characters, the cap a test holds the description to"
    }
   ],
   "lede": "A test that scans its own crate AgentOS once had a test that built a real store and wrote synthetic rows into the real work graph. I had a test added to the hook crate that scans the crate's own source and fails the build if any test constructs a store outside the isolated path. Test isolation became a property of the build, enforced by a source scan that sees a structural rule no unit test can. design <figure class=\"dv-figure\" aria-label=\"The source scan over every test in the crate, catching the one that builds a store outside the isolated path\" <span class=\"eyebrow\" Every test in the hook crate, scanned by one more test</span <div class=\"dv-pages\" style=\"margin-top: 0.6rem\" aria-hidden=\"true\" <span class=\"dv-page\"",
   "quote": "When a rule breaks once, I add a test that fails the build for the whole class of mistake.",
   "evidence": [
    "Static analysis as tests: source-scanning tests and a CI carve gate that fail the build for a whole class of mistake, such as any test building a store outside the isolated path.",
    "FFI safety across Rust and CUDA: layout tests that compare the Rust and C views of every shared struct and fail the build when they diverge.",
    "Design budgets enforced in CI: a test caps the one tool description that replaced 41,990 tokens of schemas for 44 tools at 520 characters."
   ],
   "technology_kind": "discipline"
  },
  {
   "url": "https://coreyjames.ai/technologies/streaming-statistics-in-cuda/",
   "kind": "technology",
   "title": "Streaming statistics in CUDA",
   "subtitle": "Welford and Chan moments, histogram quantiles and compare-and-swap float atomics, written once in a device library and tested on their own, so every metric kernel is numerically stable in single precision.",
   "systems": [
    "inference-fabric"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "256",
     "label": "bins in the shared-memory block histogram"
    },
    {
     "value": "10 KB",
     "label": "of shared memory for a median of millions of distances"
    },
    {
     "value": "0.4%",
     "label": "resolution of that median, about"
    }
   ],
   "lede": "Three ways single precision goes wrong Statistics over a hundred thousand vectors in single precision across thousands of threads go wrong in familiar ways: a naive variance cancels catastrophically, a sum depends on the order of the adds, and the minimum of a float cannot be taken atomically because the hardware has no such instruction. The device library under my CUDA engine solves each of those once, and every metric kernel in the Inference Fabric reads from it. design <figure class=\"dv-figure\" aria-label=\"One sum taken in two orders of arrival, naive and with a Chan merge\" <span class=\"eyebrow\" One sum, two orders of arrival</span <div class=\"dv-bars\" style=\"grid-template-columns: minmax(0, 11rem) minmax(0, 1fr) 0.5rem\" <span Naive, order one</span <span <span class=\"bar\" style=\"width: 84%;",
   "quote": "The kernels that call tested primitives inherit tested ground.",
   "evidence": [
    "CUDA kernel development: a device library of Welford and Chan moments, block reductions with broadcast variants and compare-and-swap float atomics, each with its own CUDA test.",
    "Numerically stable GPU statistics: single-precision moments that stay stable whatever the order of arrival, with the population convention fixed so GPU and CPU agree.",
    "Streaming quantiles on GPU: a 256-bin shared-memory histogram finds the median of millions of distances at about 0.4% resolution in 10 KB."
   ],
   "technology_kind": "discipline"
  },
  {
   "url": "https://coreyjames.ai/technologies/sycl/",
   "kind": "technology",
   "title": "SYCL",
   "subtitle": "ActiveKV's attention operators and its kernel patches on Intel Xe2 are SYCL, each gated on bit-identical outputs.",
   "systems": [
    "activekv"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "26%",
     "label": "faster one-row decode than BF16, reading 8-bit history directly"
    },
    {
     "value": "31%",
     "label": "less device time for the two-owner decoder than two one-row calls"
    },
    {
     "value": "256",
     "label": "registers per work-item; every candidate fits with no spills"
    },
    {
     "value": "2 KB",
     "label": "integer query cache held in registers"
    }
   ],
   "lede": "I can work at the kernel level on hardware the ecosystem has not caught up with: design the operator, fit it into the register file, prove it exact or bounded, and patch the vendor stack where it falls short. ActiveKV runs on an Intel Arc Pro GPU, a new architecture whose open kernel stacks had gaps. I wrote two kinds of SYCL: my own attention operators for the compressed history tier and the merge that joins the tiers, built on Intel's open SYCL attention sources, and patches to the vendor's kernels, credited as such. Every figure below is on one Intel Arc Pro GPU serving a 4-bit-weight build of a 27-billion-parameter hybrid recurrent-attention open-weight model. Attention that reads 8-bit history",
   "quote": "A bitwise mismatch is a finding.",
   "evidence": [
    "Intel GPU and SYCL/oneAPI engineering: attention operators reading 8-bit history without expanding it, prefill of 1,024 rows over a 32K tile cut from 18.69 ms to 8.74 ms, 9.2 percent faster than BF16.",
    "GPU kernel register-level optimisation: every candidate fitted in 256 registers with no spills, one-row decode 26% faster than BF16 and a two-owner decoder using 31% less device time.",
    "Vendor kernel patching with bit-exact gates: oneDNN and recurrent-layer patches with identical outputs, per-chunk prefill from 53.8 to 27.4 ms, and a visibility race found by bitwise comparison.",
    "Numerical reproducibility: deterministic 4-bit GEMM reductions under a validation switch, and exact arithmetic kept across 48 special-value combinations."
   ],
   "technology_kind": "runtime"
  },
  {
   "url": "https://coreyjames.ai/technologies/synthetic-training-data-generation/",
   "kind": "technology",
   "title": "Synthetic training-data generation",
   "subtitle": "The capabilities model's training corpus is generated from the tool registry by a data factory, so the model is rebuilt from the catalog whenever the catalog changes.",
   "systems": [
    "capabilities-model",
    "fafo-core"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "336",
     "label": "templated entries the statistical detector quarantined"
    },
    {
     "value": "1,958",
     "label": "synthetic distractor tools generated for the evaluation"
    },
    {
     "value": "≈30B",
     "label": "parameters in the local open model on the panel"
    }
   ],
   "lede": "Authored from the tool registry Capabilities model learns its tool catalog from data, and I decided every example would be generated from the tool registry it serves, so retraining after a catalog change is a pipeline run. Seeds come from the tool servers' own listings into a YAML registry. For each tool a panel writes intents of several kinds: paraphrases, hard negatives from pairs of tools that are easy to confuse, requests that need several tools, and long paragraphs with the real request buried inside. The panel mixes frontier models from several vendors with a local open model, and the work is split per tool and kind so no one model's habits dominate. The authoring models are third-party and open",
   "quote": "Templated output looks plentiful and teaches little.",
   "evidence": [
    "Synthetic training data generation: a corpus generated from the tool registry by a panel of model families, with a local open model of ≈30B parameters among them.",
    "Data quality gates for ML: a statistical detector quarantined 336 templated entries, with deduplication and item-by-item leakage checks against the frozen evaluation.",
    "Adversarial evaluation design: 1,958 synthetic distractor tools tested against classifiers trained to tell real from synthetic before use."
   ],
   "technology_kind": "discipline"
  },
  {
   "url": "https://coreyjames.ai/technologies/systemd/",
   "kind": "technology",
   "title": "systemd",
   "subtitle": "Every service in my estate that stays up is a locked-down systemd unit; the agent runtime, the credential service and the governance watcher among them.",
   "systems": [
    "auth-and-access-plane",
    "agentos",
    "inference-fabric",
    "fafohive"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "1 min",
     "label": "timer cadence for container cleanup"
    },
    {
     "value": "2 min",
     "label": "poller cadence in FAFOHive"
    }
   ],
   "lede": "One declared fleet for the access plane Auth and access plane holds the operations layer, and I wanted the fleet's behaviour fixed in configuration. A few dozen services sit under one stack target, with explicit ordering, and the unit files and an inventory are versioned with the code. PartOf cascades carry a dependency's restart through to its dependants, drop-ins make data-store clients wait for the network and declare cascade membership, and Docker-wrapped services are managed like native ones. Routine work such as container cleanup is a timer, visible and controllable on its own rather than a loop hidden in a script. design <figure class=\"dv-figure\" aria-label=\"A dependency restart cascading through the fleet\" <span class=\"eyebrow\" One restart, as the units see it</span",
   "quote": "I build services to be operated: declared dependencies, sandboxing on anything public, secrets handled by the init system and recurring work in the open.",
   "evidence": [
    "Linux service operations with systemd: a declared fleet under one stack target, with PartOf restart cascades and timers instead of hidden loops.",
    "Sandboxing and container hardening: the public OAuth server's unit with no new privileges, a read-only system, a system-call filter and a memory limit, secrets through LoadCredential.",
    "Inference serving architecture: pipeline services each restartable on its own, so one can be upgraded without draining the pipeline."
   ],
   "technology_kind": "platform"
  },
  {
   "url": "https://coreyjames.ai/technologies/text-embedding-models/",
   "kind": "technology",
   "title": "Text embedding models",
   "subtitle": "I ran a bake-off across embedding families for retrieval and replaced an incumbent chosen by habit with one chosen by measurement.",
   "systems": [
    "capabilities-model",
    "fafohive",
    "fafo-core"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "5",
     "label": "embedding models through one harness on the frozen evaluation"
    },
    {
     "value": "1,024",
     "label": "dimensions per vector in the memory index"
    },
    {
     "value": "568M",
     "label": "parameters in the multilingual memory embedder"
    }
   ],
   "lede": "A bake-off instead of habit Capabilities model needed a retrieval baseline strong enough that beating it would mean something. The incumbent embedding model had been picked only because the rest of the estate used it. design <blockquote class=\"dv-quote\" <p Estate consistency is no evidence.</p </blockquote I had a bake-off run on the frozen evaluation. The candidates went through the same harness on ONNX Runtime, and disqualifiers for latency and context length stopped an accurate but undeployable model from winning. The winner went into a fusion baseline with BM25. GPU scoring runs with TF32 pinned off, after a known-answer control showed that the precision setting changed rankings. The models are third-party open models; the bake-off, the serving architecture and the retrieval",
   "quote": "Estate consistency is no evidence.",
   "evidence": [
    "Embedding model selection: a bake-off of 5 embedding models through one harness on the frozen evaluation, with latency and context-length disqualifiers.",
    "Retrieval baselines: a BM25 and dense fusion baseline with every weight chosen by sweep, built as strong as it honestly could be even where it tied my own model.",
    "Embedding serving architecture: a multilingual 568M-parameter embedder moved from an in-process Python bridge to its own server, producing 1,024-dimension vectors."
   ],
   "technology_kind": "model"
  },
  {
   "url": "https://coreyjames.ai/technologies/tiled-pairwise-kernels/",
   "kind": "technology",
   "title": "Tiled pairwise kernels",
   "subtitle": "One tiling design makes every quadratic cluster metric exact at a hundred thousand members, with bounded memory and no sampling.",
   "systems": [
    "inference-fabric"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "6",
     "label": "accumulator types the pairwise kernels declare"
    },
    {
     "value": "≈8 KB",
     "label": "of shared memory per block for a tile pair"
    },
    {
     "value": "1",
     "label": "atomic per tile into the cluster totals"
    }
   ],
   "lede": "One tile shape for every quadratic metric Half of my cluster metrics are quadratic: they need every pair of members. The tiled pairwise machinery in the Inference Fabric's CUDA engine makes those metrics exact at a hundred thousand members with bounded memory, and it is the step that let me take every sampling cap out of the metrics in Removing the sampling caps. The cluster is cut into tiles of sixteen rows by sixty-four, and the grid is flattened so one block owns one tile pair. Diagonal tiles visit each pair once over the upper triangle, rectangular tiles visit the full cross product, and a tile prefix sum maps a flat block index back to its cluster and tile pair",
   "quote": "Five billion distances do not fit, and a second sweep is cheap.",
   "evidence": [
    "CUDA kernel development: one tiling design for every quadratic cluster metric, exact over 5 billion pairs in a cluster of a hundred thousand members.",
    "GPU memory and contention design: tile pairs in ≈8 KB of shared memory per block, register accumulation and 1 atomic per tile, with every thread at every barrier.",
    "Extensible kernel design: six declared accumulator types share one tile loop, and a second pass recomputes distances instead of storing them."
   ],
   "technology_kind": "discipline"
  },
  {
   "url": "https://coreyjames.ai/technologies/tls-and-mtls/",
   "kind": "technology",
   "title": "TLS and mTLS",
   "subtitle": "TLS with hot certificate rotation on every public surface; mutual TLS between my hosts for LAN GPU provisioning.",
   "systems": [
    "inference-fabric",
    "fafo-core",
    "fafohive",
    "agent-swarm",
    "helix",
    "auth-and-access-plane",
    "capabilities-model"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "1.2/1.3",
     "label": "the only TLS versions the public fronts accept"
    },
    {
     "value": "0",
     "label": "certificate files on disk for the embedding-service client"
    },
    {
     "value": "once",
     "label": "SSH login per host, then never again"
    }
   ],
   "lede": "SSH once, then mutual TLS for a GPU fleet Inference Fabric and FAFO Core and Function Forge needed to drive Docker on spare LAN workstations, and I did not want a shell login to be the control channel for a GPU fleet. One call bootstraps the machine over SSH, issues it a certificate from my own certificate authority, reconfigures its Docker daemon to accept only mutually authenticated TLS, checks the handshake and rolls back if the check fails. From then on every container start, log read and teardown on that host goes over mutual TLS. A LAN machine becomes controllable capacity without Kubernetes and without a shared password. design <figure class=\"dv-figure\" aria-label=\"One LAN host, from bootstrap onwards\" <div style=\"display: grid;",
   "quote": "I treat transport security as something the systems operate themselves: they issue, rotate and check certificates without a person in the loop.",
   "evidence": [
    "Zero-trust networking: LAN GPU hosts bootstrapped once over SSH, then controlled only over mutual TLS to the Docker daemon, with a handshake check and automatic rollback.",
    "Certificate management: certificates rotated under traffic through an atomic swap, with no agent seat disconnected.",
    "Transport security architecture: one trust anchor per transport, plaintext connection strings refused when configuration loads, public fronts on TLS 1.2 and 1.3 only."
   ],
   "technology_kind": "protocol"
  },
  {
   "url": "https://coreyjames.ai/technologies/tmux/",
   "kind": "technology",
   "title": "tmux",
   "subtitle": "tmux is how my governance platform drives vendors' interactive command-line tools as persistent governed sessions, and how I verify that a message actually landed.",
   "systems": [
    "agentos",
    "agent-swarm",
    "helix"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "PID 1",
     "label": "the supervisor's place in each seat's container"
    },
    {
     "value": "1",
     "label": "vendor TUI per tmux session"
    },
    {
     "value": "2",
     "label": "Enter keys for the vendor whose composer swallows the first"
    },
    {
     "value": "9",
     "label": "tests in the transport experiment for checking seats"
    }
   ],
   "lede": "Driving vendor CLIs as governed sessions AgentOS governs coding agents that live inside the vendors' own command-line tools, and those tools are terminal programs built for a person at a keyboard. I chose to drive them the way a person does, through a terminal, and to make every delivery's outcome explicit. The supervisor for each agent seat owns a tmux session in its container. Operators attach to the same session to watch or take over, so humans and the automation see the same screen. The wider program is in Directing AI coding agents at program scale. design <figure class=\"dv-figure\" aria-label=\"One terminal screen, two attachers\" <div style=\"display: grid; grid-template-columns: 1fr 2fr 1fr; gap: 12px; align-items: center; margin-top: 0.6rem\" <span class=\"lbl\" style=\"font-size:",
   "quote": "I can turn tools built for people into dependable machine interfaces and still keep duplicates out.",
   "evidence": [
    "Agent orchestration: vendor coding CLIs driven as governed sessions, 1 vendor TUI per tmux session under a supervisor at PID 1 of each container.",
    "Delivery semantics for terminal interfaces: every delivery ends accepted, rejected or unknown, confirmed from the transcript and never retried when unknown.",
    "Separation of duties for AI work: the transport for checking seats chosen by a 9-test experiment on write-scope integrity."
   ],
   "technology_kind": "platform"
  },
  {
   "url": "https://coreyjames.ai/technologies/token-aware-gpu-batch-scheduling/",
   "kind": "technology",
   "title": "Token-aware GPU batch scheduling",
   "subtitle": "The token is the unit of GPU scheduling in my broker: shape-pure batches packed to each card's declared limits, across two different GPUs.",
   "systems": [
    "inference-fabric",
    "fafo-core"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "0.421%",
     "label": "padding waste across both cards"
    },
    {
     "value": "99.9%",
     "label": "key-value cache hit rate on both cards, zero shape switches"
    },
    {
     "value": "2,280",
     "label": "lanes in use at 22 percent lane pressure"
    },
    {
     "value": "≈17,800",
     "label": "lane reuses a second, one new lane every two seconds"
    }
   ],
   "lede": "The token as the unit of scheduling Inference Fabric started from a backlog of billions of tokens and two GPUs of different sizes. A queue that hands each card whatever arrived next mixes short and long prompts, fills the gaps with padding, thrashes the engine's key-value cache and sends the smaller card work it cannot hold. I made the token the broker's unit of scheduling and split the problem into two separate axes: a signature for cacheable structure and lanes for length. design <figure class=\"dv-figure\" aria-label=\"A batch of mixed lengths full of padding against a lane-packed batch of one shape\" <div class=\"dv-two\" <div <span class=\"eyebrow\" Whatever arrived next</span <div style=\"display: grid; gap: 3px; margin-top: 0.6rem\" <div style=\"display: flex; height: 10px;",
   "quote": "The rule I wrote at the top of that code: spend structure before spending waste.",
   "evidence": [
    "Token-aware scheduling: a Rust broker that packs shape-pure batches to each GPU's declared limits, at 0.421% padding waste across both cards.",
    "KV-cache-aware batching: a 64-bit shape signature per prompt template held a 99.9% key-value cache hit rate on both cards with zero shape switches.",
    "Message broker and queue design: rolling lanes with a pressure-adaptive threshold, 2,280 lanes in use at 22 percent lane pressure and ≈17,800 lane reuses a second."
   ],
   "technology_kind": "discipline"
  },
  {
   "url": "https://coreyjames.ai/technologies/tokio/",
   "kind": "technology",
   "title": "Tokio",
   "subtitle": "Tokio is under every Rust service I run. Where the hot path is small, as in the broker's dispatch loop, I keep it synchronous on purpose and say why.",
   "systems": [
    "fafo-core",
    "agent-swarm",
    "helix",
    "fafohive",
    "agentos",
    "inference-fabric"
   ],
   "technologies": [],
   "stats": [],
   "lede": "Cancellation and lock order for the GPU conductor FAFO Core and Function Forge accepts commands such as pause, scale and drain while jobs run on GPUs, and I knew that combination breeds stuck workers and lock-order deadlocks. I built the conductor on Tokio with two rules. Each worker handle aborts its task when dropped, so a worker cancelled mid-flight releases its GPU memory without every code path having to clean up. The conductor's locks follow an acquisition order written in the code beside them. design <figure class=\"dv-figure\" aria-label=\"A cancelled worker and its GPU memory\" <div style=\"position: relative; display: grid; grid-template-columns: minmax(84px, 28%) 1fr; gap: 22px 10px; align-items: center; margin-top: 0.7rem; padding-bottom: 14px\" <span class=\"lbl\" style=\"font-size: 0.78rem; text-align: left\" Command</span <div",
   "quote": "I use an async runtime as an architectural tool: I design cancellation, backpressure and lock order up front, and I know where to leave it out.",
   "evidence": [
    "Rust systems engineering: async services on Tokio with worker handles that abort on drop, so a cancelled GPU worker releases its memory.",
    "Concurrency design: lock acquisition order written beside the locks, backpressure drainers, and push-to-poll fallback when queues saturate.",
    "Low-latency system design: the broker's dispatch path kept off the async runtime as a single-owner actor on blocking threads."
   ],
   "technology_kind": "framework"
  },
  {
   "url": "https://coreyjames.ai/technologies/tree-sitter/",
   "kind": "technology",
   "title": "tree-sitter",
   "subtitle": "tree-sitter parses a multi-language monorepo into the chunks and edges behind my code search and dependency graph.",
   "systems": [
    "fafohive"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "19,000",
     "label": "files in the multi-language monorepo"
    },
    {
     "value": "294,000",
     "label": "chunks from the monorepo"
    },
    {
     "value": "100",
     "label": "lines, the longest unit kept whole"
    },
    {
     "value": "40",
     "label": "lines per overlapping sub-chunk"
    }
   ],
   "lede": "Answers from the code's structure FAFOHive serves AI agents that ask questions about a large multi-language monorepo, and I wanted their answers to come from the code's structure. Embeddings of arbitrary line windows give agents half a function and a guess. I decided to parse every file with tree-sitter and use the syntax tree twice: to cut code into meaningful chunks for search, and to extract the dependency graph the code tools traverse. design <figure class=\"dv-figure\" aria-label=\"Where each method cuts the same file\" <span class=\"eyebrow\" One file · three functions and a type</span <div style=\"display: grid; grid-template-columns: 3fr 5fr 2fr 4fr; gap: 3px; margin-top: 0.7rem\" <span style=\"height: 14px; border-radius: 4px; background: var(--ink-3)\" </span <span style=\"height: 14px; border-radius: 4px; background: var(--ink-3)\"",
   "quote": "I give AI agents computed facts about code and limit the model to explaining them.",
   "evidence": [
    "Code intelligence for AI agents: a 19,000-file multi-language monorepo parsed with tree-sitter into 294,000 syntax-aligned chunks for code search.",
    "Static dependency analysis: calls, imports and implementations extracted into a generation-versioned graph whose edges appear only when both ends are indexed.",
    "Evidence-grounded LLM output: dependency tracing by bounded search in SQL, with a model allowed to narrate only edges the graph holds."
   ],
   "technology_kind": "framework"
  },
  {
   "url": "https://coreyjames.ai/technologies/typescript/",
   "kind": "technology",
   "title": "TypeScript",
   "subtitle": "TypeScript builds the meeting-stage app, the relay between Teams and my agent, the public site runtime, and the in-house social integrations.",
   "systems": [
    "auth-and-access-plane",
    "helix",
    "fafohive"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "16,200",
     "label": "lines in the weather-intelligence MCP server"
    },
    {
     "value": "9",
     "label": "public data-service clients behind both surfaces"
    },
    {
     "value": "12,400",
     "label": "lines of TypeScript plugins on an unmodified chat server"
    },
    {
     "value": "6,500",
     "label": "lines in the vendor event intake, tests and migrations included"
    }
   ],
   "lede": "One MCP server, sized for two kinds of client Auth and access plane includes a product I built to learn what an enterprise agent platform needs from an MCP server: a weather-intelligence server on Express 5 and the official MCP TypeScript SDK. I gave it two surfaces. Desktop assistants get the full set over the local stdio transport; Microsoft Copilot Studio gets a trimmed set over Streamable HTTP, with the session header its connector expects, because that platform copes poorly with large catalogs. design <figure class=\"dv-figure\" aria-label=\"The public data services behind both surfaces\" <div style=\"display: flex; flex-wrap: wrap; gap: 14px 18px; margin-top: 0.4rem; align-items: flex-end\" aria-hidden=\"true\" <div class=\"cyl\" </div <div class=\"cyl\" </div <div class=\"cyl\" </div <div class=\"cyl\" </div <div class=\"cyl\"",
   "quote": "Building the same server on two official SDKs showed me which decisions were mine and which were the SDK's.",
   "evidence": [
    "MCP server design: a 16,200-line TypeScript weather-intelligence MCP server, the full tool set over stdio and a trimmed set over Streamable HTTP for Copilot Studio.",
    "Event ingestion and idempotency: a 6,500-line vendor event intake that checks signatures over raw bytes, stores before acknowledging and delivers each keyed batch once.",
    "Platform extension without forking: 12,400 lines of TypeScript plugins on an unmodified open-source team chat server."
   ],
   "technology_kind": "language"
  },
  {
   "url": "https://coreyjames.ai/technologies/unix-domain-sockets/",
   "kind": "technology",
   "title": "Unix domain sockets",
   "subtitle": "Unix sockets are the transport between my governance hooks and their runtime, between the voice engine and its clients, and between the capabilities model's decoder and its callers.",
   "systems": [
    "helix",
    "agentos",
    "fafohive",
    "capabilities-model"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "1 MiB",
     "label": "cap on every frame a privileged server will read"
    },
    {
     "value": "3",
     "label": "JSON-lines protocols over local sockets"
    },
    {
     "value": "1",
     "label": "account each server will answer"
    }
   ],
   "lede": "A privileged manager behind typed local protocols Helix has to create and control vendor CLI sessions, which takes privileges I did not want in the processes that talk to models. I split the privileged part into a small manager and put Unix sockets between it and everything else. The control center speaks JSON-lines protocols over local sockets: service to session manager, service to the per-vendor adapters, and browser terminal attach. Every server checks the connecting process's user ID against the one account allowed to call it, because a socket path says nothing about who connected, and a hard frame cap keeps a misbehaving client from making a privileged process allocate without bound. Adapter replies carry correlation fence tokens, so a",
   "quote": "I design local process boundaries with the care most people reserve for network APIs: typed, size-limited, authenticated by peer identity and safe to restart.",
   "evidence": [
    "Least-privilege process design: a privileged session manager behind local sockets that answers 1 account, checked by the caller's user ID.",
    "Protocol design: 3 JSON-lines protocols over local sockets with a 1 MiB frame cap, fence tokens and an on-disk outbox that survives restarts.",
    "Zero-inbound networking: a provider with no TCP port, reached through a private socket and a native-messaging host."
   ],
   "technology_kind": "protocol"
  },
  {
   "url": "https://coreyjames.ai/technologies/vendor-integration-reverse-engineering/",
   "kind": "technology",
   "title": "Vendor-integration reverse engineering",
   "subtitle": "When vendor documentation runs out I probe the platform itself, capture the wire, and compose what actually works.",
   "systems": [
    "auth-and-access-plane",
    "agentos",
    "agent-swarm",
    "helix",
    "capabilities-model"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "≈300",
     "label": "lines in the edge Worker built around the connector's real behaviour"
    },
    {
     "value": "20 ms",
     "label": "audio pacing the real-time media SDK expects"
    },
    {
     "value": "30 min",
     "label": "soak with a forced mid-call reconnect"
    }
   ],
   "lede": "A connector learned from the wire Auth and access plane has to expose private tools to Microsoft Copilot Studio, whose MCP connector behaves differently from its documentation. I decided to learn the connector from my own edge logs and build to what it does, and each undocumented quirk gets explicit handling. I built an edge Worker around what I found, with two key slots because rotation has to work against a client configuration I do not control. A cache-busting procedure covers the API hub, which can keep returning stale answers from a fixed server. design <figure class=\"dv-figure\" aria-label=\"How far each kind of request from the connector gets through the edge Worker\" <div style=\"display: grid; grid-template-columns: 10rem minmax(0, 1fr); gap: 0.5rem",
   "quote": "I modify none of the vendors' products; the work is understanding them precisely and building around them safely.",
   "evidence": [
    "Vendor integration reverse engineering: an MCP connector learned from my own edge logs, answered by an edge Worker of ≈300 lines built to its real behaviour.",
    "Microsoft Teams real-time media: a bridge to the real-time media SDK's buffer lifetimes and 20 ms pacing, soak-tested for 30 min with a forced mid-call reconnect.",
    "Dependency pinning by observed contract: coding-CLI behaviours pinned to the version they were observed on, so an upgrade is a decision."
   ],
   "technology_kind": "discipline"
  },
  {
   "url": "https://coreyjames.ai/technologies/vllm/",
   "kind": "technology",
   "title": "vLLM",
   "subtitle": "vLLM is the engine ActiveKV lives inside, patched at the scheduler, worker and attention backend, and the server under my local open-source models.",
   "systems": [
    "activekv",
    "capabilities-model",
    "agent-swarm"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "128,000",
     "label": "token histories for a 27B hybrid model on one card"
    },
    {
     "value": "32 GB",
     "label": "the single card it runs on"
    },
    {
     "value": "36%",
     "label": "more sustained throughput than a mixed 4-bit/8-bit control"
    },
    {
     "value": "3%",
     "label": "higher perplexity than full precision"
    }
   ],
   "lede": "Moving a request's history off the card ActiveKV began with a limit I kept hitting in vLLM: it keeps a model's whole key-value cache for a request in GPU memory, and its offload is a prefix cache that reuses prompts it has seen. Once a request's history outgrew the card, the request could not continue. I treated prefix reuse and active-context tiering as separate problems from the start. design <figure class=\"dv-figure\" aria-label=\"Prefix reuse against active-context tiering\" <div class=\"dv-two\" <div <span class=\"eyebrow\" Prefix cache · reused prompts</span <div class=\"dv-pages\" style=\"margin-top: 0.6rem\" <span class=\"dv-page hot\" </span <span class=\"dv-page hot\" </span <span class=\"dv-page hot\" </span <span class=\"dv-page\" </span <span class=\"dv-page\" </span <span class=\"dv-page\" </span <span class=\"dv-page hot\" </span <span class=\"dv-page hot\" </span <span",
   "quote": "A flat throughput curve under concurrency now sends me to the client first.",
   "evidence": [
    "vLLM internals: ActiveKV built into vLLM at its scheduler, key-value connector, worker, attention backend and plugin system, delivered as binaries plus a patch.",
    "KV-cache offload for LLM inference: attention history in pinned host memory with a bounded working set on the card, 128,000-token histories for a 27B model on one 32 GB card.",
    "LLM quantization (4-bit): a 27B model quantized to a format the stock XPU build serves, 36% more sustained throughput for 3% higher perplexity.",
    "C++ and native ports with parity proof: the runtime moved from Python inside vLLM to native C++ with bit-identical output in every parity cell."
   ],
   "technology_kind": "runtime"
  },
  {
   "url": "https://coreyjames.ai/technologies/web-crawling-and-document-extraction/",
   "kind": "technology",
   "title": "Web crawling and document extraction",
   "subtitle": "A native crawler and section extractor for PDFs, Markdown and HTML feed the reference index behind my memory service.",
   "systems": [
    "fafohive"
   ],
   "technologies": [],
   "stats": [],
   "lede": "A reference library beside the code The memory capability in FAFOHive serves agents that port patterns from vendor SDKs and call vendor APIs. design <blockquote class=\"dv-quote\" <p An agent that guesses an API produces code that compiles and fails.</p </blockquote I decided agents should cite the vendor's own source and documentation, so I built a reference library next to the code index: vendor SDK repositories, API documentation and crawled developer sites, each in its own named index so a vendor sample never surfaces as the team's code, and all searched under one contract with the same tools as the working code. Other systems lean on these indexes. Microsoft's Teams SDK, Graph API reference and Copilot Studio samples back the work",
   "quote": "An agent that guesses an API produces code that compiles and fails.",
   "evidence": [
    "Web crawling and document extraction: a Rust documentation crawler honouring robots.txt and rate limits, stripping boilerplate and re-crawling incrementally.",
    "Document structuring for RAG: PDF, Markdown and HTML split into hierarchical sections with breadcrumbs and page ranges, with model-written section summaries before embedding.",
    "Retrieval for AI agents: vendor SDKs, API documentation and crawled sites in separate named indexes under one search contract with the working code."
   ],
   "technology_kind": "discipline"
  },
  {
   "url": "https://coreyjames.ai/technologies/webauthn/",
   "kind": "technology",
   "title": "WebAuthn",
   "subtitle": "Hardware-key sign-in for the person who approves an OAuth grant, on an alternate entrypoint of the server, with the assistants' path left unchanged.",
   "systems": [
    "auth-and-access-plane"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "300 s",
     "label": "life of a login challenge"
    },
    {
     "value": "1 day",
     "label": "before the locking change was reverted"
    }
   ],
   "lede": "Hardware keys at the consent screen Auth and access plane is the OAuth server through which commercial AI assistants and my own agents get access to my tool estate. The control point there is a person approving each grant on a consent screen. I added WebAuthn hardware-key sign-in to an alternate entrypoint of that server, so the person approving a grant can be asked to prove presence with a security key or platform authenticator instead of a password. design <figure class=\"dv-figure\" aria-label=\"What the person proves before approving\" <span class=\"eyebrow\" Before</span <div style=\"position: relative; display: grid; grid-template-columns: repeat(3, minmax(0, 1fr)); margin-top: 0.8rem\" <span style=\"position: absolute; left: 16.666666666666668%; right: 16.666666666666668%; top: 8px; height: 2px; background: var(--rule)\" </span <div style=\"position: relative; text-align: center;",
   "quote": "A person's consent is the control, and a stricter gate nobody can pass weakens the system.",
   "evidence": [
    "OAuth and identity architecture: WebAuthn hardware-key sign-in for the person who approves an OAuth grant, returning them to the exact grant they were approving.",
    "Security design: login challenges that expire after 300 s, and a registration lock reverted because it locked out every legitimate assistant."
   ],
   "technology_kind": "protocol"
  },
  {
   "url": "https://coreyjames.ai/technologies/webhook-ingestion-and-verification/",
   "kind": "technology",
   "title": "Webhook ingestion and verification",
   "subtitle": "Inbound vendor events are signature-checked, batched durably and delivered to the team that caused them, in the gateway and in the in-house social integrations.",
   "systems": [
    "fafohive",
    "fafo-core"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "300 s",
     "label": "replay window on every signed delivery"
    },
    {
     "value": "6",
     "label": "attempts at most, at widening intervals, on network and server errors only"
    },
    {
     "value": "5 min",
     "label": "between checks for events left unanswered past their deadline"
    }
   ],
   "lede": "Three rules in both event planes FAFOHive receives webhooks in two event planes, and I set the same three rules for both: check the signature over the untouched body, store before acknowledging, and keep event redelivery separate from action repetition. Signatures are checked over raw bytes, because re-serialised JSON no longer matches. Events may be redelivered; payment and social actions are never repeated. design <figure class=\"dv-figure\" aria-label=\"The signed body as received against the same event re-serialised, with the changed bytes marked\" <span class=\"eyebrow\" The bytes the vendor signed</span <div style=\"display: grid; grid-template-columns: repeat(32, minmax(0, 1fr)); gap: 2px; margin-top: 0.4rem\" aria-hidden=\"true\" <span style=\"height: 16px; border-radius: 2px; background: var(--tone)\" </span <span style=\"height: 16px; border-radius: 2px; background: var(--tone)\" </span <span style=\"height: 16px; border-radius:",
   "quote": "An unanswered event escalates on a timer, so \"answer every customer\" is something the system checks.",
   "evidence": [
    "Webhook ingestion and verification: signatures checked over the raw body before parsing, events stored before acknowledging, redelivery kept apart from action repetition.",
    "Message signing and replay protection: a shared HMAC contract with a 300 s replay window and two secret slots for rotation.",
    "Reliable delivery: retries at widening intervals up to 6 attempts on network and server errors only, and breach events every 5 min for anything unanswered past its deadline."
   ],
   "technology_kind": "discipline"
  },
  {
   "url": "https://coreyjames.ai/technologies/websocket/",
   "kind": "technology",
   "title": "WebSocket",
   "subtitle": "One authenticated WebSocket per call carries the binary audio link between Teams and my voice engine, and survives a mid-call reconnect.",
   "systems": [
    "helix"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "2",
     "label": "implementations held to byte-identical output"
    },
    {
     "value": "20 ms",
     "label": "audio pacing the media SDK expects"
    },
    {
     "value": "30 min",
     "label": "soak with a forced mid-call reconnect"
    }
   ],
   "lede": "A media driver on Windows, the intelligence on my side Helix answers Microsoft Teams calls with a voice engine on my own GPUs under Linux, and Teams hands raw call audio only to a Windows application built on Microsoft's real-time media SDK. I kept all intelligence on my side and made the Windows piece a media driver, joined to the engine by a WebSocket link carrying a binary media protocol I designed. design <figure class=\"dv-figure\" aria-label=\"Where the work happens on a Teams call\" <div style=\"display: flex; align-items: center; gap: 0; margin-top: 0.8rem\" <div style=\"flex: 1; border-radius: 12px; border: 1.5px solid var(--ink-3); padding: 10px\" <span class=\"lbl\" style=\"font-size: 0.74rem\" Windows on Azure · .NET media bridge</span <div style=\"height: 10px; margin-top: 8px; border-radius:",
   "quote": "I can design a real-time protocol across two languages, two clouds and a vendor SDK with strict rules, and prove it under soak and fault before I call it finished.",
   "evidence": [
    "Microsoft Teams real-time media: one authenticated full-duplex WebSocket per call between a .NET media bridge and a Rust voice engine, admitted by tenant, persona and fingerprint.",
    "Binary protocol design: 2 implementations, C# and Rust, held to byte-identical output with shared golden vectors, audio paced at 20 ms.",
    "Fault tolerance in real-time systems: a 30 min soak and a forced reconnect inside the same call, with audio from the gap dropped."
   ],
   "technology_kind": "protocol"
  },
  {
   "url": "https://coreyjames.ai/technologies/write-behind-persistence/",
   "kind": "technology",
   "title": "Write-behind persistence",
   "subtitle": "Writes in my substrate go through a write-behind queue and a batching writer, so producers never block on the database.",
   "systems": [
    "postgresql-fabric",
    "fafo-core",
    "inference-fabric"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "196 → 0",
     "label": "deadlocks, before and after one schema change on the shared path"
    },
    {
     "value": "2 s",
     "label": "the slowest batches before that change"
    }
   ],
   "lede": "One governed write path FAFO Core and Function Forge runs functions that fan out to many GPU workers on several machines, each producing results in bursts. If every worker wrote to PostgreSQL itself, the database would see as many writers as there are workers, each holding connections and locks while it waits on a GPU. I made a house rule. design <blockquote class=\"dv-quote\" <p Functions read from PostgreSQL directly, and every write leaves the function as a message that one governed writer applies.</p </blockquote Workers hand off results and move on, and the writer, not the workers, sets the database's write load. Schema validation lives on that single path and nowhere else, so a malformed row is rejected in one",
   "quote": "Functions read from PostgreSQL directly, and every write leaves the function as a message that one governed writer applies.",
   "evidence": [
    "Write-behind persistence: every write from GPU-scale workers leaves as a message one governed writer applies, so the database takes writes at a rate it can sustain.",
    "PostgreSQL performance tuning: deadlocks on the shared write path went 196 → 0 after one schema change, measured from committed rows rather than queue intake."
   ],
   "technology_kind": "discipline"
  },
  {
   "url": "https://coreyjames.ai/technologies/x-api/",
   "kind": "technology",
   "title": "X API",
   "subtitle": "An in-house X integration where one service owns the rate limit, the monthly budget and the send log, and never re-sends an action whose outcome is unknown.",
   "systems": [
    "fafohive"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "36",
     "label": "tools in the integration"
    },
    {
     "value": "21",
     "label": "reading and analysis tools"
    },
    {
     "value": "15",
     "label": "action tools, each with an inverse"
    }
   ],
   "lede": "Routes chosen from measured behaviour FAFOHive needed an X integration that AI agents could use for research and replies without burning a metered budget or posting twice. I built it behind the same governed tool gateway as every other tool, with the same identity, attribution and audit, on two programmatic routes: the official X API v2, and a third-party X data API that costs less for public research. A third route, the operator's own signed-in session, covers actions the official API does not allow here. The official API goes through an allow-listed transport with OAuth 2.0 and PKCE for user context, and its Activity webhooks are checked before ingestion. Routing is fixed per action, chosen from measured platform behaviour. When",
   "quote": "A duplicated public post is worse than a missing one.",
   "evidence": [
    "Tool synthesis and governed API integration: an X integration of 36 tools, 21 for reading and 15 for actions, with read and act on separately authorised endpoints.",
    "Rate limiting and budget control: one service owns the rate limit, a monthly budget with reservations and a durable send log, and every result states its cost.",
    "Exactly-once delivery: every write read back, and a write whose outcome is unknown never resent automatically."
   ],
   "technology_kind": "platform"
  },
  {
   "url": "https://coreyjames.ai/technologies/yaml/",
   "kind": "technology",
   "title": "YAML",
   "subtitle": "Tools, personas, execution profiles and tool schemas are YAML in my estate, compiled and hash-pinned rather than parsed at runtime.",
   "systems": [
    "agent-swarm",
    "agentos",
    "fafo-core"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "40",
     "label": "tools declared in YAML"
    },
    {
     "value": "545",
     "label": "lines of schema validating every persona"
    },
    {
     "value": "12,000",
     "label": "lines of catalog, personas, groundings and profiles"
    },
    {
     "value": "18",
     "label": "multi-action MCP tools on the control surface"
    }
   ],
   "lede": "Tools and agent classes as data Agent Swarm rests on one idea of mine, that tools are the platform, and I wanted adding a tool or an agent class to be a declaration with no new code. The tools are YAML documents of four kinds, each with a Rust dispatcher. Every tool must ship with golden fixtures that pin its behaviour and attack fixtures that try to break it, such as an injection attempt against a shell template, and the build fails for a tool without them. See Tools are the platform. design <figure class=\"dv-figure\" aria-label=\"Four kinds of tool document, each with its fixtures\" <div style=\"display: grid; grid-template-columns: repeat(auto-fit, minmax(110px, 1fr)); gap: 12px; margin-top: 0.8rem\" <div style=\"text-align: center\" <div style=\"width:",
   "quote": "I use declarative configuration to make platforms extensible and keep them strict: every declaration is validated, tested or compiled before it takes effect.",
   "evidence": [
    "Declarative tool and agent definition: 40 tools declared as YAML documents of four kinds, each with golden and attack fixtures the build enforces.",
    "Schema validation: a 545-line schema validating every persona at load time, over about 12,000 lines of catalog, personas, groundings and profiles.",
    "Code generation from schemas: 18 multi-action MCP tools whose dispatch code is generated from YAML schemas at build time."
   ],
   "technology_kind": "language"
  },
  {
   "url": "https://coreyjames.ai/technologies/zero-inbound-network-exposure/",
   "kind": "technology",
   "title": "Zero-inbound network exposure",
   "subtitle": "No host in my estate accepts an inbound connection. Everything arrives through authenticated tunnels or a private mesh, and every public surface is fronted by TLS and rate limits.",
   "systems": [
    "auth-and-access-plane",
    "helix",
    "fafohive",
    "inference-fabric"
   ],
   "technologies": [],
   "stats": [
    {
     "value": "0",
     "label": "inbound connections from the internet"
    },
    {
     "value": "3",
     "label": "outbound tunnels, one per purpose"
    },
    {
     "value": "1",
     "label": "public component in front of a vendor platform: a small edge Worker"
    }
   ],
   "lede": "Outbound tunnels, one per purpose Auth and access plane holds my estate to one rule I set early: no service accepts an inbound connection from the internet. Everything public arrives through outbound-only tunnels, one per purpose, separating the main estate, business event intake and the social-platform integrations, so trouble on one surface stays there and I can cut any one surface without touching the others. Where a hosted service needs a public name, NGINX terminates TLS behind the tunnel, and TLS termination, rate limits and security headers sit in that one front layer. Where a vendor platform such as Microsoft Copilot Studio needs a public endpoint, it reaches the tools through an edge Worker. Helix exposes its voice endpoint through",
   "quote": "A service that needs no listener gets none.",
   "evidence": [
    "Zero-trust and zero-inbound networking: 0 inbound connections from the internet; everything public arrives through 3 outbound tunnels, one per purpose.",
    "Edge security design: 1 small edge Worker as the only public component in front of a vendor platform, and NGINX with TLS, security headers and per-endpoint rate limits elsewhere.",
    "Mutual TLS for fleet control: LAN GPU workstations bootstrapped by SSH once, then controlled only over mutual TLS with a private certificate authority."
   ],
   "technology_kind": "discipline"
  }
 ]
}