Not every agent skill is deeply technical. Some of the highest-value skills capture the ordinary, recurring work that fills an organization's days — drafting a particular kind of document, following a review process, preparing a standard analysis, handling a routine request a specific way. These "general business skills" are broadly applicable, easy to get wrong by being too generic, and quietly transformative when done right. This post is about capturing everyday business work as reliable agent skills.
The highest-value skills often capture ordinary recurring work — a standard document, a review process, a routine analysis. Their failure mode is being too generic; the value is entirely in your specifics. Why frequency-times-people makes them high-leverage, and how to find them.
A technically excellent AI system that nobody uses has delivered zero value. The last mile of an AI deployment is not the model — it's fitting the system into how real people actually do their jobs, designing an interface that handles uncertainty honestly, and managing the human change of introducing AI into someone's work. This is where deployments succeed or quietly fail, and where the forward deployed engineer's non-technical skills matter most.
A technically excellent AI system that nobody uses has delivered zero value. The last mile of an AI deployment is not the model — it's fitting the system into how real people actually do their jobs, designing an interface that handles uncertainty honestly, and managing the human change of introducing AI into someone's work. Human-in-the-loop, calibrated reliance, autonomy levels, and change management.
Building a good model is maybe half the work; running a recommender in production is the other half. Real systems must serve in milliseconds, stay fresh as the catalog and tastes change, handle cold start gracefully, resist the filter bubbles their own optimization creates, and be monitored like any critical service. This closing post assembles everything into what it takes to run a recommender for real — and how to build one.
Building a good model is half the work; running a recommender in production is the other half. Real systems must serve in milliseconds, stay fresh as the catalog and tastes change, handle cold start gracefully, resist the filter bubbles their own optimization creates, and be monitored like any critical service. This closing post assembles everything — and gives a practical path to building one.
Every large language model runs on a GPU, but most engineers treat the GPU as a black box that "does the math fast." Understanding why it's fast — and, more usefully, why it's often not as fast as its spec sheet promises — is the foundation of inference engineering. This series works below the serving layer: not how to run an inference server, but how the silicon actually executes a model and where the real bottlenecks live.
Every LLM runs on a GPU, but the spec-sheet FLOPS number is a near-fiction in practice. Why neural nets map onto GPUs (matrix multiply, SMs, tensor cores), and the governing intuition of the series: compute is cheap, data movement is expensive.
A single skill makes an agent reliable at one task; the real power comes from how skills combine into patterns of work. An agent equipped with a library of well-designed skills can compose them, chain them, and apply them across a workflow — turning point capabilities into end-to-end reliable work. This post is about the patterns that emerge when skills work together, and how to think about an agent's skill library as a system rather than a pile of parts.
A single skill does one task; the power is in combination. Composition (many focused skills for one task — combinatorial leverage), chaining (skills across a workflow — reliable whole processes), and treating the skill library as a curated, compounding, shared system that mirrors your real work.
You cannot ship AI you cannot measure, and no enterprise grants a probabilistic system authority over real work on faith. Both problems have the same answer: evaluation. Building the customer's own evaluation set — real examples, their definition of correct — is how the AI forward deployed engineer turns "it seemed good in the demo" into a reliability number, and that number is how trust gets earned.
You cannot ship AI you cannot measure, and no enterprise grants a probabilistic system authority over real work on faith. Both problems have the same answer: evaluation. Building the customer's own eval set — real examples, their definition of correct — turns 'it seemed good in the demo' into a reliability number, and that number is how trust gets earned. Offline/online eval, safe failure, and trust.
A recommender that scores well offline can flop in production, and a metric that looks like success can quietly harm the product. Evaluating recommenders is genuinely hard: offline metrics only approximate real behavior, the only ground truth is a live A/B test, and the very act of recommending shapes the data you learn from next. This post covers offline metrics, online testing, the gap between them, and the feedback loops that make evaluation a moving target.
A recommender that scores well offline can flop in production, and a metric that looks like success can quietly harm the product. Evaluation is genuinely hard: offline metrics only approximate real behavior, the only ground truth is a live A/B test, and the very act of recommending shapes the data you learn from next. Offline metrics, online testing, the offline-online gap, and feedback loops.
A knowledge graph is not a project you finish; it's a system you run. Ontologies evolve, data drifts, quality decays, and the graph has to stay trustworthy while the business changes around it. This closing post covers the operational reality — governing the ontology, keeping the graph correct over time, and the honest question most teams skip: given the cost, when is a knowledge graph actually the right tool? It ties the series into a decision you can make with clear eyes.
A knowledge graph is a system you run, not a project you finish. Governing the ontology as it evolves, keeping the populated graph correct (freshness, re-resolution, provenance), and the honest question: given the cost, when is a knowledge graph the right tool — and when is a table or plain vector RAG cheaper and enough?
A good agent skill is a small piece of information architecture: the right scope, a clear trigger, well-structured instructions, and only the knowledge the task needs — all shaped by the context-window discipline of post 2. Building one is less about clever prompting and more about thinking like a technical writer and a software designer at once. This post is the practical craft of designing and building a skill that an agent uses reliably.
Building a skill is information architecture under a context budget. Scoping to one coherent capability, structuring it (sharp trigger, clear prescriptive instructions, curated knowledge, deferred depth), writing for the agent as a capable-but-uninformed reader, and iterating empirically while pruning ruthlessly.
A frontier model knows the public internet and nothing about the customer. All the value of an AI deployment comes from the opposite: making the model reason over the customer's own documents, records, and knowledge. Grounding is the technical heart of the AI forward deployed engineer's job — connecting a general model to a specific company's messy, permissioned, incomplete data so its answers are about their reality, not the model's imagination.
A frontier model knows the public internet and nothing about the customer. All the value of an AI deployment comes from the opposite: making the model reason over the customer's own documents, records, and knowledge. Grounding — retrieval-augmented generation over messy, permissioned, incomplete data — is the technical heart of the AI FDE's job. With an interactive reference-architecture diagram.
Modern large-scale recommenders — the ones running at the biggest consumer platforms — are built on neural networks. Deep learning didn't replace the core ideas (embeddings, two stages) so much as supercharge them: neural models learn richer embeddings, ingest far more features, and capture complex non-linear patterns that dot products can't. This post covers the two workhorses — two-tower retrieval and neural ranking — that power today's systems.
Modern large-scale recommenders are built on neural networks — not replacing the core ideas (embeddings, two stages) but supercharging them. This post covers the two workhorses: two-tower models for retrieval (the neural evolution of matrix factorization, built for fast ANN search) and rich neural ranking models that score the shortlist with cross-features, sequences, and multiple objectives.
In a large organization the hardest data problem isn't storage or speed — it's that nobody agrees what "customer," "revenue," or "active user" actually means, and every team computes them differently. A semantic layer is the ontology applied to the enterprise: a shared, governed definition of the business's concepts and relationships that sits above the scattered data and gives everyone — dashboards, analysts, and now AI agents — one consistent meaning to build on. This is where ontologies deliver their most concrete business value.
The enterprise ontology made operational: a governed layer that defines the business's entities, relationships, and metrics once, so dashboards, analysts, and AI agents all inherit the same definitions. Why 'revenue' means three things, and why AI made the semantic layer urgent — an agent is only as correct as its grasp of your terms.