Configuration: Separate Policy from Mechanism
If changing a setting requires changing code, your system is tighter than it needs to be.
Discover more
Debugging SCORM 2004 Like a Developer
SCORM 2004 does not fail silently. It tells you exactly what went wrong. If you are not reading error codes, validating API calls, and tracing lifecycle state, you are not debugging. You are guessing.
Agent Evaluation and Tracing: Why Prompting Is Not Enough
Prompting can improve a single run, but it cannot prove that an agent workflow is reliable. This article explains how traces, scorecards, offline evals, and online monitoring turn agent quality into an engineering discipline.
Inheritance Tax: The Cost of Rigid Hierarchies
Inheritance feels elegant at first, but deep hierarchies often charge interest later.
Migrating from SCORM 1.2 to SCORM 2004
Migrating from SCORM 1.2 to SCORM 2004 is not a version upgrade. It is a behavioral redesign. If your migration strategy only updates API calls and manifest versioning, you are not migrating. You are creating hidden inconsistencies.
Tracing Agent Behavior: The Fastest Way to Understand What Went Wrong
If an agent fails and you only have the final answer, you are debugging blind. This article explains how useful traces expose the exact step, tool, state, or context failure that actually broke the run.
Transforming Programming: From State to Flow
When you reduce hidden state and focus on clear transformations, debugging turns from detective work into simple reasoning.
SCORM 2004 Editions Explained
SCORM 2004 is not one specification. It is a family of editions. If your content behaves differently across LMS platforms, the issue may not be your implementation. It may be how each system interprets a specific edition.
Retries, Backoff, and Recovery Paths for Tool-Using Agents
Reliable agents are not the ones that never fail. They are the ones that fail into the right path. Here is how to classify tool failures into retry, replan, user input, or hard stop, and why retry policy belongs at the tool boundary.
Juggling the Real World: Designing for Reality
Real world software fails not because it is complex, but because it was designed for ideal conditions.