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. 01 Agent Kernel Architecture: The Complete Guide A comprehensive guide to the components of an agent kernel: the cycle, the AST engine, the cognitive memory engine, and the isolated context.
2. 02 Agent Kernel vs Agent Framework A framework supplies components a developer assembles. A kernel runs the cycle itself, verifies outcomes, and updates its own weights.
3. 03 BX-System vs. LangGraph: Kernel vs. Framework LangGraph is a framework for building stateful agents. BX-System is a kernel that runs its own cycle and updates its weights without reprogramming.
4. 04 How to Evaluate an Agent Kernel: The 6-Point Checklist A checklist for evaluating an agent kernel: the cycle, verification, weight updates, repair rules, kill switch, and efficiency.
5. 05 What 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. 06 Declarative Flows vs Imperative Scripts A declarative flow names the tools and the order. The kernel executes the flow; the flow does not execute itself.
7. 07 Implementation Guide: Signing Tools with SHA-256 A 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. 08 How to Build a Declarative Flow A practical guide to structuring a declarative flow: defining the tools, setting the order, and establishing the verification contracts.
9. 09 One Cycle: Generate, Verify, Record, Update One cycle reads stored context, generates a tool or flow, verifies the outcome, records the result, and updates strategy weights.
10. 010 How an Agent Generates Its Own Tools A tool is generated as code, signed, verified against an expected outcome, and recorded. A failed tool is not trusted.
11. 011 Outcome Verification: Expected vs Actual Verification compares the actual outcome of a tool against the expected outcome and records the verdict.
12. 012 How to Verify Agent Output Verification: define the expected outcome, execute the tool, compare actual with expected, record the verdict, update the weights.
13. 013 Strategy Weights: How Outcomes Change Behavior Strategy weights are updated after every verified outcome. A strategy that failed is deprioritized; the code does not change.
14. 014 Reward Between 0 and 1: Designing the Verdict Scale A reward is a scalar between 0 and 1 computed from a verified outcome. It updates the strategy weights.
15. 015 Undeclared Tool Calls: When a Tool Is Invented An undeclared tool call is a tool that is invoked without being declared in a flow. The kernel rejects it before execution.
16. 016 The AST Engine: Rule-Based Code Repair The AST engine parses generated code, applies policy rules, writes the corrected version, and updates the signature.
17. 017 Why LLM-Generated Code Fails in Production Generated code fails when there is no rule and no verification. The AST engine applies rules; verification confirms the outcome.
18. 018 Defining Repair Rules for Generated Code A repair rule names a violation and the correction the AST engine applies. Rules are declarative and applied without manual review.
19. 019 Kill Switch and Isolated Context A central kill switch stops execution. Isolation keeps context with immutable snapshots so a stop and a resume do not corrupt state.
20. 020 RAM-Only Execution for Core Modules Core modules run RAM-only. Nothing is written to disk during execution, so a stopped cycle leaves no executable residue.
21. 021 Encrypting Tool Packages with AES-GCM Every package is encrypted with AES-GCM. The package is decrypted in the isolated context and executed without persisting.
22. 022 Stable State: What the Kernel Returns To Stable state is the condition to which the kernel returns after a repair or after a failed verification.
23. 023 Pausing and Resuming an Autonomous Kernel Pausing stops the cycle but preserves weights and memory. Resuming reads the stored context and continues from it.
24. 024 Workflow Context and Memory State Memory state is the accumulated knowledge each cycle adds to. Workflow context records the current run.
25. 025 Context Loss Between Runs Context loss happens when a run does not read stored memory. The kernel resumes from workflow context and memory state.
26. 026 Measuring Efficiency Without Guessing Efficiency is measured as the ratio of energy consumed to result achieved. It is not measured by volume of output.
27. 027 The Cost of Always-On Agents An always-on agent spends resources between tasks. The kernel weighs energy consumed against result achieved in each decision.
28. 028 Behavior Change Without New Code A strategy that failed is deprioritized and a strategy that worked is raised. The code is unchanged; the weights are.
29. 029 Why Prompt-Only Agents Break at Scale A prompt-only agent has no cycle, no verification, and no weight update. It cannot adapt from its own outcomes.
30. 030 Unverified Automation: The Silent Failure Unverified automation is a silent failure: the tool runs, nothing is compared, and the outcome is assumed. The kernel records a verdict.
31. 031 Why AI Agents Loop Forever A loop is a cycle without verification. The kernel stops the loop because a cycle ends at a verified outcome, not at a guess.
32. 032 Continuous operation Continuous 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. 033 Self-protection Self-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. 034 Adaptation Adaptation 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. 035 Automatic repair Automatic 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. 036 Efficiency Efficiency 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. 037 The Five Operating Principles in One Page Five principles: continuous operation, self-protection, adaptation, automatic repair, efficiency. Each has a dedicated article.
38. 038 Signing Every Tool with SHA-256 Every tool is signed with SHA-256. A signature change means the code changed; an unchanged signature means the code is as verified.
39. 039 Role Profiles: Prompt Prefix, Bias, Routing A role profile sets the prompt prefix, the bias profile, and the task routing for a language model call.