BX-System

BX-System is not an agent framework. It is an agent kernel that generates its own tools, verifies them against expected outcomes, learns from the results, and follows five operating principles.

Five operating principles

1. 01Agent Kernel Architecture: The Complete GuideA comprehensive guide to the components of an agent kernel: the cycle, the AST engine, the cognitive memory engine, and the isolated context.
2. 02Agent Kernel vs Agent FrameworkA framework supplies components a developer assembles. A kernel runs the cycle itself, verifies outcomes, and updates its own weights.
3. 03BX-System vs. LangGraph: Kernel vs. FrameworkLangGraph is a framework for building stateful agents. BX-System is a kernel that runs its own cycle and updates its weights without reprogramming.
4. 04How to Evaluate an Agent Kernel: The 6-Point ChecklistA checklist for evaluating an agent kernel: the cycle, verification, weight updates, repair rules, kill switch, and efficiency.
5. 05What Is an Agent Kernel?An agent kernel coordinates tools through declarative flows, verifies their behavior, and updates its own strategy weights from verified outcomes.
6. 06Declarative Flows vs Imperative ScriptsA declarative flow names the tools and the order. The kernel executes the flow; the flow does not execute itself.
7. 07Implementation Guide: Signing Tools with SHA-256A step-by-step guide to how the kernel signs tools with SHA-256 and updates the signature after the AST engine performs a repair.
8. 08How to Build a Declarative FlowA practical guide to structuring a declarative flow: defining the tools, setting the order, and establishing the verification contracts.
9. 09One Cycle: Generate, Verify, Record, UpdateOne cycle reads stored context, generates a tool or flow, verifies the outcome, records the result, and updates strategy weights.
10. 010How an Agent Generates Its Own ToolsA tool is generated as code, signed, verified against an expected outcome, and recorded. A failed tool is not trusted.
11. 011Outcome Verification: Expected vs ActualVerification compares the actual outcome of a tool against the expected outcome and records the verdict.
12. 012How to Verify Agent OutputVerification: define the expected outcome, execute the tool, compare actual with expected, record the verdict, update the weights.
13. 013Strategy Weights: How Outcomes Change BehaviorStrategy weights are updated after every verified outcome. A strategy that failed is deprioritized; the code does not change.
14. 014Reward Between 0 and 1: Designing the Verdict ScaleA reward is a scalar between 0 and 1 computed from a verified outcome. It updates the strategy weights.
15. 015Undeclared Tool Calls: When a Tool Is InventedAn undeclared tool call is a tool that is invoked without being declared in a flow. The kernel rejects it before execution.
16. 016The AST Engine: Rule-Based Code RepairThe AST engine parses generated code, applies policy rules, writes the corrected version, and updates the signature.
17. 017Why LLM-Generated Code Fails in ProductionGenerated code fails when there is no rule and no verification. The AST engine applies rules; verification confirms the outcome.
18. 018Defining Repair Rules for Generated CodeA repair rule names a violation and the correction the AST engine applies. Rules are declarative and applied without manual review.
19. 019Kill Switch and Isolated ContextA central kill switch stops execution. Isolation keeps context with immutable snapshots so a stop and a resume do not corrupt state.
20. 020RAM-Only Execution for Core ModulesCore modules run RAM-only. Nothing is written to disk during execution, so a stopped cycle leaves no executable residue.
21. 021Encrypting Tool Packages with AES-GCMEvery package is encrypted with AES-GCM. The package is decrypted in the isolated context and executed without persisting.
22. 022Stable State: What the Kernel Returns ToStable state is the condition to which the kernel returns after a repair or after a failed verification.
23. 023Pausing and Resuming an Autonomous KernelPausing stops the cycle but preserves weights and memory. Resuming reads the stored context and continues from it.
24. 024Workflow Context and Memory StateMemory state is the accumulated knowledge each cycle adds to. Workflow context records the current run.
25. 025Context Loss Between RunsContext loss happens when a run does not read stored memory. The kernel resumes from workflow context and memory state.
26. 026Measuring Efficiency Without GuessingEfficiency is measured as the ratio of energy consumed to result achieved. It is not measured by volume of output.
27. 027The Cost of Always-On AgentsAn always-on agent spends resources between tasks. The kernel weighs energy consumed against result achieved in each decision.
28. 028Behavior Change Without New CodeA strategy that failed is deprioritized and a strategy that worked is raised. The code is unchanged; the weights are.
29. 029Why Prompt-Only Agents Break at ScaleA prompt-only agent has no cycle, no verification, and no weight update. It cannot adapt from its own outcomes.
30. 030Unverified Automation: The Silent FailureUnverified automation is a silent failure: the tool runs, nothing is compared, and the outcome is assumed. The kernel records a verdict.
31. 031Why AI Agents Loop ForeverA loop is a cycle without verification. The kernel stops the loop because a cycle ends at a verified outcome, not at a guess.
32. 032Continuous operationContinuous operation is the principle by which BX-System generates, verifies, records, and learns without waiting for commands. Each cycle reads stored memory, produces new work, and updates its own weights.
33. 033Self-protectionSelf-protection is the principle by which BX-System protects its code, its tools, its packages, and its execution context through layered mechanisms that operate before, during, and after execution.
34. 034AdaptationAdaptation is the principle by which BX-System changes its behavior based on accumulated outcomes instead of repeating a fixed solution. Every verified result updates the strategy weights; a strategy that failed is deprioritized.
35. 035Automatic repairAutomatic repair is the principle by which BX-System corrects faulty code without manual review. The AST engine detects rule violations and corrects them; the kernel returns to a stable state.
36. 036EfficiencyEfficiency is the principle by which BX-System aims to use as few resources as possible. Each decision is weighed by energy consumed against result achieved.
37. 037The Five Operating Principles in One PageFive principles: continuous operation, self-protection, adaptation, automatic repair, efficiency. Each has a dedicated article.
38. 038Signing Every Tool with SHA-256Every tool is signed with SHA-256. A signature change means the code changed; an unchanged signature means the code is as verified.
39. 039Role Profiles: Prompt Prefix, Bias, RoutingA role profile sets the prompt prefix, the bias profile, and the task routing for a language model call.