Published March 2026<\/p>\n
Author:<\/strong> William Christopher Anderson Large language models are stateless. Every call begins from nothing. The entire burden of continuity \u2014 what happened before, what matters now, what the system has learned \u2014 falls on whatever context is stuffed into the prompt window. Today’s agent systems respond to this constraint with brute force: they pack as much raw text as possible into every call, hope the model attends to the right parts, and accept that the model forgets everything between sessions.<\/p>\n This approach is simultaneously expensive and unreliable. It is expensive because every token sent to the model incurs cost, and most of those tokens are irrelevant to the current task. It is unreliable because the model has no mechanism to distinguish signal from noise in a bloated context window \u2014 the important instruction on line 400 competes for attention with the boilerplate on line 12.<\/p>\n The Compiled Context Runtime (CCR) is an architectural model that eliminates both problems. It introduces three structural innovations:<\/p>\n Process definitions<\/strong> \u2014 Agent workflows codified as versioned, executable YAML specifications. Each process declares its steps, gates, knowledge requirements, and trigger conditions. The agent’s creativity goes into executing the steps, not remembering them.<\/p>\n<\/li>\n Compiled context injection<\/strong> \u2014 A compilation pipeline that retrieves relevant knowledge, compresses it into a lossless format (CTX), and injects only what is needed for the current process step. The context window receives precision-compiled packages, not raw text dumps.<\/p>\n<\/li>\n Memory and context chains<\/strong> \u2014 Persistent, linked data structures in a local database that capture the full history of agent interactions, decisions, corrections, and execution outcomes. Chains compile into CTX packages on demand, giving the model access to effectively unlimited historical depth while staying within the token window.<\/p>\n<\/li>\n<\/ol>\n The consequence is a system where the context window is no longer a hard limit. It becomes a viewport \u2014 a precision-scoped lens into a local store of potentially millions of memories, thousands of execution records, and hundreds of thousands of embeddings. The model sees exactly what it needs for the current step. Nothing more. Nothing less.<\/p>\n The economic implications are significant. By reducing input tokens per task by approximately 88% and eliminating exploratory calls through deterministic process execution, the CCR model cuts LLM API costs by an order of magnitude. At enterprise scale, this represents millions of dollars in annual savings per organization. At global scale \u2014 across the hundreds of millions of knowledge workers, analysts, researchers, writers, and developers adopting LLM-assisted workflows \u2014 the aggregate savings exceed billions of dollars annually.<\/p>\n This paper describes the architectural model, the compilation pipeline, the memory system, the learning loop that makes processes and context progressively more efficient, and the economic analysis that quantifies the impact.<\/p>\n Current approaches to LLM-based agent systems treat the context window as a fixed-size container into which raw text is packed before each inference call. This produces three systemic failures: excessive token cost from irrelevant context, unreliable model behavior from attention dilution, and complete memory loss between sessions. The Compiled Context Runtime addresses these failures through process-driven execution (codified workflows that eliminate prompt-dependent behavior), compiled context injection (a pipeline that retrieves, compresses, and scopes knowledge to the current step), and persistent memory chains (linked data structures that give the model access to unbounded historical depth through precision compilation). This paper presents the architectural model, the compilation format, the memory and context chain data structures, the process discovery and refinement loop, and a quantitative analysis of token economics at individual, enterprise, and global scale. The system is local-first by design: all data \u2014 process definitions, execution history, knowledge embeddings, compiled context packages \u2014 resides on the user’s machine. No workflow data crosses a network boundary except the compiled context injected into the LLM inference call itself.<\/p>\n Large language models are functions. They accept a sequence of tokens and produce a sequence of tokens. They retain nothing between calls. Every inference begins from a blank state, and whatever continuity the system exhibits must be constructed entirely from the input context.<\/p>\n This is a fundamental architectural constraint, and the industry’s response to it has been remarkably uniform: pack more into the context window. Conversation history is appended. Retrieval-augmented generation (RAG) inserts document fragments. System prompts grow to thousands of tokens of instructions. The result is a context window that serves simultaneously as instruction manual, conversation log, knowledge base, and working memory \u2014 a single undifferentiated buffer asked to do the work of four distinct systems.<\/p>\n The consequences are predictable. Important instructions are buried among retrieved passages. Relevant history competes with irrelevant history for the model’s attention. Token costs scale linearly with the amount of context stuffed into each call, regardless of how much of that context is actually used. And when the session ends, everything is lost.<\/p>\n Agent systems amplify every failure mode. An agent is not a single inference call \u2014 it is a sequence of calls, each building on the last, often spanning hours of work. An agent reviewing a pull request might make twenty calls: reading files, understanding context, analyzing changes, composing feedback. At each call, the agent system must reconstruct the relevant context from scratch, because the model remembers nothing from the previous call.<\/p>\n The common solution is to carry forward the entire conversation history. This means that call twenty contains the full transcript of calls one through nineteen \u2014 most of which is irrelevant to the current task of composing a final review comment. The token cost of the twentieth call dwarfs its informational content.<\/p>\n More critically, the agent has no structured memory. It cannot recall what it learned three sessions ago. It cannot look up a decision it made last week. It cannot walk a chain of related corrections to understand the current state of a preference. Every session begins from whatever fits in the system prompt, and everything else is gone.<\/p>\n The Compiled Context Runtime (CCR) inverts the relationship between the model and its context. Instead of the context window being a container that the system fills, it becomes a viewport that the runtime controls.<\/p>\n The runtime maintains three independent systems:<\/p>\n These three systems compose to produce a model of agent execution where the context window is used surgically \u2014 receiving only what the current step requires \u2014 while the actual depth of available context is limited only by local storage.<\/p>\n The CCR is not coupled to any specific language model. Compiled CTX packages are plain text \u2014 any model that accepts text input can consume them. Process definitions are YAML \u2014 they describe what to do, not how any particular model should do it. Memory chains are data structures \u2014 they store and retrieve knowledge independently of which model uses it.<\/p>\n Critically, the model is not statically configured \u2014 it is dynamically selected<\/strong>. When a step in a process needs execution, the runtime evaluates the task requirements (reasoning depth, code generation, speed constraints, data sensitivity), checks available models and their capabilities, and selects the optimal model for that specific step. The process definition does not say “use Claude” or “use GPT” \u2014 it describes the work, and the runtime matches the work to the best available model. This means:<\/p>\n The CCR model is local-first by design, not by preference. This is an architectural requirement, not a deployment choice.<\/p>\n Process definitions encode an organization’s workflows. Execution history records what an agent has done and learned. Memory chains capture every decision, correction, and preference accumulated over months of use. Knowledge embeddings index proprietary content, internal documentation, and domain-specific reference material.<\/p>\n None of this data should cross a network boundary. It is operationally sensitive, competitively valuable, and privacy-critical. The only data that leaves the user’s machine is the compiled context package injected into the LLM inference call \u2014 and that package contains only what the current step requires, compiled into a format that strips structural metadata.<\/p>\n Local-first is what makes the system trustworthy. If the memory system required shipping data to a cloud service, adoption would be structurally limited to organizations willing to externalize their workflows. Local-first removes that constraint entirely.<\/p>\n Before defining how processes are represented, the CCR establishes the fundamental cycle that governs all agent work. Every action an agent takes is an instance of one of five primitives, executed in cycle:<\/p>\n Orchestrate<\/strong> \u2014 Invoke meta-learning. Pull the latest state. Read the knowledge index. Look up relevant knowledge by topic. Compile context. Analyze dependencies. Decompose the task. Dispatch.<\/p>\n<\/li>\n Execute<\/strong> \u2014 Do the work. Write code, configure systems, run tests, produce artifacts. This is the only primitive that produces external output.<\/p>\n<\/li>\n Learn<\/strong> \u2014 Analyze outcomes at two levels:<\/p>\n<\/li>\n Context-learning:<\/strong> Evaluate the domain \u2014 what was discovered about the subject matter, the working environment, the user’s preferences. Update knowledge and memory chains.<\/p>\n<\/li>\n Build<\/strong> \u2014 Create new processes, knowledge artifacts, or tools when Learn identifies gaps. A repeated ad-hoc sequence becomes a process definition. A missing knowledge topic becomes a new entry. A missing capability becomes a new tool.<\/p>\n<\/li>\n Refine<\/strong> \u2014 Improve existing processes, knowledge, and tools when Learn identifies weaknesses. A slow step gets optimized. A stale knowledge reference gets updated. A process gate that fails too often gets its preconditions adjusted.<\/p>\n<\/li>\n<\/ol>\n The cycle:<\/strong> Orchestrate \u2192 Execute \u2192 Learn \u2192 Build\/Refine (if needed) \u2192 Orchestrate (better)<\/p>\n The five primitives are not arbitrary. They are the minimal set required for a self-improving execution system:<\/p>\n Remove any one and the system loses a critical capability. Add a sixth and it can be expressed as a composition of the existing five. The primitives are orthogonal and complete.<\/p>\n Every process definition in the CCR is a codification of the five primitives applied to a specific workflow:<\/p>\n The five primitives are the theory. Process definitions are the implementation. The CCR makes the cycle explicit, executable, and self-improving.<\/p>\n The first structural innovation of the CCR is the separation of workflow definition from workflow execution.<\/p>\n In conventional agent systems, the workflow lives in the prompt. A system prompt might instruct the agent: “First, check CI status. Then read the failing test. Then fix the test. Then run the test suite. Then commit.” The agent follows these instructions \u2014 if it attends to them, if they fit in the context window, if it doesn’t hallucinate an alternative sequence.<\/p>\n In the CCR, the workflow is a data structure:<\/p>\n This definition is stored in a database, versioned, and executable. The runtime reads it and executes each step in sequence. The model is invoked at each step with exactly the context that step requires \u2014 not a prompt full of instructions it might or might not follow.<\/p>\n Gates are preconditions evaluated before execution begins or before individual steps execute. They are binary \u2014 pass or fail \u2014 and their failure halts the process with a recorded reason.<\/p>\n Gates serve two purposes. First, they prevent the agent from executing in invalid states \u2014 attempting to commit when tests are failing, or beginning work without an execution context. Second, they create a verifiable execution contract. A process with three gates and six steps produces a deterministic sequence of checkpoints that can be audited after the fact.<\/p>\n Each process declares which knowledge topics it needs. The runtime resolves these references against the knowledge store before execution begins. This is not retrieval-augmented generation \u2014 it is declarative context scoping. The process author specifies exactly what the model should know for this workflow. The runtime compiles it. The model receives it.<\/p>\n This eliminates the two failure modes of RAG: retrieving irrelevant passages (because the process author specified exactly what’s needed) and missing relevant passages (because the knowledge references are explicit and verified at process definition time).<\/p>\n Process definitions are object-oriented. A process can extend<\/strong> another process, inheriting its steps, gates, and knowledge references while overriding or adding to them. This is structural inheritance \u2014 the same concept as class inheritance in Java or C#, applied to workflow definitions.<\/p>\n The inheritance model supports:<\/p>\n Concrete processes extend this base:<\/p>\n This is polymorphism applied to workflows. A Just as object-oriented systems separate interface from implementation, the CCR separates process contracts<\/strong> from process implementations<\/strong>. A process interface defines what a process must do \u2014 its required steps, gates, and knowledge references \u2014 without specifying how.<\/p>\n Any process that declares Process interfaces enable:<\/p>\n This is the Interface Segregation Principle applied to processes. Interfaces are small, focused contracts. Processes implement the ones relevant to their domain. The compiler enforces the contracts. The runtime dispatches polymorphically.<\/p>\n Process definitions are not interpreted \u2014 they are compiled<\/strong>. The compilation pipeline is analogous to class loading in the JVM or assembly loading in the CLR: YAML source is parsed, validated, linked, and emitted as an executable runtime object.<\/p>\n Compilation stages:<\/strong><\/p>\n Parse<\/strong> \u2014 YAML source is deserialized into a raw ProcessDefinition AST (abstract syntax tree). Syntax errors are caught here \u2014 malformed YAML, missing required fields, invalid types.<\/p>\n<\/li>\n Validate<\/strong> \u2014 The AST is validated against the process schema. Semantic errors are caught: duplicate step IDs, circular inheritance, references to nonexistent gates, abstract steps that aren’t overridden, knowledge references that don’t resolve. Validation produces a list of errors and warnings. A process with errors cannot proceed to linking. Warnings are recorded but do not block compilation.<\/p>\n<\/li>\n Resolve inheritance<\/strong> \u2014 If the process extends a parent, the compiler loads the parent (recursively, for chains of inheritance), merges inherited steps\/gates\/knowledge with the child’s overrides, and verifies that all abstract steps have been implemented.<\/p>\n<\/li>\n Link<\/strong> \u2014 Symbolic references are resolved to concrete objects. Knowledge topic names are resolved to file paths. Gate names are bound to evaluator functions. Step actions are bound to handler callables. The result is a Emit<\/strong> \u2014 The LinkedProcess is registered in the process table and cached. It is ready for execution. The compiled form is stored alongside the source YAML, so recompilation is only needed when the source changes.<\/p>\n<\/li>\n<\/ol>\n Compile-time guarantees:<\/strong><\/p>\n Because processes are validated at compile time, the runtime can make guarantees that interpreted systems cannot:<\/p>\n A process that compiles will not fail due to structural errors at runtime. Runtime failures are limited to actual execution issues \u2014 a test that fails, a file that’s missing, an API that’s down. The structural integrity is guaranteed by the compiler.<\/p>\n Every modification to a process creates a new version. Execution records link to the version that was active at execution time. This produces a complete audit trail: which version of which process produced which outcome, with which knowledge references, at which time.<\/p>\n Version history enables the refinement loop described in Section 8.<\/p>\n The Compiled Context Runtime is a managed runtime<\/strong> in the same sense as the JVM or the CLR. It is not a script runner \u2014 it is a full execution environment that manages the lifecycle of process objects, provides memory management with garbage collection, implements multi-level caching, offers observability through tracing and debugging, and is extensible through a messaging bus.<\/p>\n The analogy is precise:<\/p>\n The CCR implements a three-tier cache modeled on CPU cache hierarchies:<\/p>\n L1 \u2014 In-Memory Hot Cache.<\/strong> Recently compiled CTX packages, recently linked processes, and recently resolved knowledge topics. Access time: microseconds. Size: bounded by memory (configurable, default 256MB). Eviction policy: adaptive replacement cache (ARC) \u2014 balances recency and frequency. This is where the runtime looks first for any compiled artifact.<\/p>\n L2 \u2014 SQLite Warm Cache.<\/strong> Compiled artifacts that have been evicted from L1 but are still likely to be needed. Serialized to disk in a SQLite database. Access time: single-digit milliseconds. Size: bounded by disk (configurable, default 2GB). Eviction policy: time-aware LFU \u2014 items that haven’t been accessed within a configurable window are evicted. Promotion to L1 occurs on access.<\/p>\n L3 \u2014 Cold Storage.<\/strong> Full compilation artifacts archived for historical reference. This tier is not accessed during normal execution \u2014 it exists for auditing and recompilation. Items promoted from L3 go to L2 first, then L1 on access.<\/p>\n Cache warming.<\/strong> On startup, the runtime warms the cache by preloading the most frequently used processes and their knowledge references. The warming strategy is derived from execution history \u2014 processes executed most often in the last 30 days are preloaded. This means the first execution after startup is nearly as fast as subsequent ones.<\/p>\n The CCR manages a large volume of runtime objects: memory nodes, context chains, execution records, compiled CTX packages, cached compilation artifacts. Not all of these need to persist forever. The generational garbage collector reclaims objects that are no longer reachable, following the same generational hypothesis as the JVM: most objects die young.<\/p>\n Three generations:<\/strong><\/p>\n Gen 0 (Nursery)<\/strong> \u2014 Newly created objects: fresh memory nodes, in-progress execution records, temporary CTX compilations. Collected frequently (every N allocations or every M minutes). Most objects die here \u2014 a temporary compilation for a single step is used once and discarded.<\/p>\n<\/li>\n Gen 1 (Survivor)<\/strong> \u2014 Objects that survived one or more Gen 0 collections. These have demonstrated some persistence \u2014 a memory node that’s been referenced by another node, an execution record that’s been finalized, a CTX package that’s been accessed multiple times. Collected less frequently.<\/p>\n<\/li>\n Gen 2 (Tenured)<\/strong> \u2014 Long-lived objects: established memory chains, frequently-accessed knowledge packages, historical execution records marked for retention. Collected rarely. Objects in Gen 2 are the permanent knowledge base \u2014 the accumulated expertise described in Section 6.<\/p>\n<\/li>\n<\/ul>\n Collection algorithm:<\/strong> Mark-sweep with reference counting. The collector identifies root objects (active execution contexts, pinned memory chains, cached processes), traces all reachable objects from roots, and sweeps unreachable objects. Reference counts provide fast detection of isolated garbage; the full mark-sweep handles cycles.<\/p>\n Promotion criteria:<\/strong> An object is promoted from Gen N to Gen N+1 when it survives a configurable number of collections (default: 2 for Gen 0\u21921, 5 for Gen 1\u21922). Objects can also be explicitly promoted (pinned) by the user or by the runtime when they’re referenced by a long-lived chain.<\/p>\n A runtime without observability is a black box. The CCR provides full instrumentation for debugging, tracing, and monitoring:<\/p>\n Execution tracing.<\/strong> Every process execution produces a trace \u2014 a structured record of every step executed, every gate evaluated, every knowledge reference resolved, every CTX package compiled, every model invocation made, and every outcome recorded. Traces are linked to execution contexts and stored in the execution record. They can be inspected after the fact to understand exactly what happened and why.<\/p>\n Step-level debugging.<\/strong> The runtime supports breakpoints at the step level. A step can be marked as a breakpoint in the process definition or at runtime. When a breakpoint step is reached, execution pauses, and the current state is surfaced: the compiled context that would be injected, the gate results, the execution history so far. The user can inspect, modify context, or resume.<\/p>\n Structured logging.<\/strong> All runtime events are emitted as structured log entries with correlation IDs that link to the active execution context. Log levels: TRACE (every internal operation), DEBUG (compilation and linking details), INFO (step execution, gate results), WARN (non-fatal issues), ERROR (step failures, gate failures).<\/p>\n Metrics.<\/strong> The runtime exposes metrics for monitoring: Diagnostic commands.<\/strong> The CLI exposes diagnostic tools: The runtime is extensible because it is built on a messaging bus<\/strong>. Every component in the system communicates through typed messages on the bus. The runtime itself does not call components directly \u2014 it publishes events, and components subscribe to the events they care about.<\/p>\n This means the runtime is open for extension without modification:<\/p>\n The bus scales from in-process (single agent) to IPC (multi-agent on one machine) to network (distributed agents). The same subscription model works at every scale because the message format is uniform and the delivery mechanism is pluggable.<\/p>\n Because processes are compiled with full validation, the compilation pipeline can power developer tooling:<\/p>\n Real-time validation.<\/strong> As a user edits a process YAML file, the compiler runs continuously, surfacing errors and warnings inline \u2014 missing knowledge references, unresolved gates, inheritance conflicts, abstract steps that need implementation. This is the process equivalent of a TypeScript language server providing red squiggles as you type.<\/p>\n Autocomplete.<\/strong> The compiler knows the full schema, all registered gates, all registered actions, all knowledge topics in the index. It can provide autocomplete suggestions for every field in a process definition.<\/p>\n Inheritance visualization.<\/strong> For processes that extend other processes, the IDE can show the resolved inheritance chain \u2014 which steps are inherited, which are overridden, which knowledge references come from which ancestor. This is the process equivalent of a class hierarchy viewer.<\/p>\n Execution dry-run.<\/strong> The IDE can simulate process execution without invoking the LLM \u2014 evaluating gates against current state, resolving knowledge references, computing the viewport allocation, and showing exactly what context would be injected at each step. This lets process authors validate their workflows before committing them.<\/p>\n Diff and history.<\/strong> Process versions are stored with full history. The IDE can show diffs between versions, highlight what changed, and correlate version changes with execution outcome changes from the refinement engine.<\/p>\n The Process IDE is not a separate product \u2014 it is a natural consequence of the compiler architecture. Any system that compiles with full validation can power tooling. The CCR’s compiler produces the same kind of structured output (AST, error list, resolved symbols) that a language compiler produces, and the same kinds of tools can be built on top of it.<\/p>\n The CCR compilation pipeline transforms raw knowledge and historical context into compressed, scoped packages injected into the model at each process step.<\/p>\n The pipeline operates in four stages:<\/p>\n Retrieval<\/strong> \u2014 The process step’s knowledge references are resolved against the local knowledge store. Memory chains and context chains relevant to the current task are retrieved via vector similarity search.<\/p>\n<\/li>\n Scoping<\/strong> \u2014 Retrieved content is filtered to what the current step actually needs. A six-step process does not carry step one’s context through step six unless the process definition explicitly requires it.<\/p>\n<\/li>\n Compilation<\/strong> \u2014 Scoped content is compiled into CTX format \u2014 a lossless semantic compression that preserves all meaning while reducing token count. The compilation is structural: redundant framing is removed, cross-references are resolved inline, and hierarchical relationships are encoded in a compact notation.<\/p>\n<\/li>\n Injection<\/strong> \u2014 The compiled CTX package is placed into the model’s context window alongside the step-specific instructions. The model receives a single, coherent, compressed context that contains exactly what it needs.<\/p>\n<\/li>\n<\/ol>\n The CTX format is a lossless compression scheme for structured knowledge. It was developed independently for compiling research whitepapers into compact reference formats and has been validated across documents ranging from 5,000 to 30,000 words.<\/p>\n The format achieves 40-60% token reduction on narrative text and 60-84% reduction on structured knowledge (tables, hierarchies, reference material). The compression is lossless in the sense that all semantic content is preserved \u2014 a model consuming the CTX version of a document has access to the same information as a model consuming the original, but at a fraction of the token cost.<\/p>\n The format is not a general-purpose compression algorithm. It is specifically designed for LLM consumption: the output is valid text that the model can read directly. No decompression step is required. The model simply reads a more compact representation of the same information.<\/p>\n The most significant cost reduction comes not from compression but from scoping. A conventional agent system might inject 50,000 tokens of context into every call \u2014 the full conversation history, the full retrieved documents, the full system prompt. The CCR injects only what the current step needs.<\/p>\n Consider a six-step process where each step requires different knowledge:<\/p>\n Average context per step: 1,667 tokens. Total across six steps: 10,000 tokens. A conventional system would inject the same 50,000-token context six times: 300,000 tokens. The CCR uses 97% fewer input tokens for the same workflow.<\/p>\n The context window is ephemeral. When a session ends, the model’s state is destroyed. Any knowledge accumulated during the session \u2014 corrections, preferences, decisions, learned context \u2014 is lost unless explicitly persisted somewhere external.<\/p>\n Current approaches to persistence are primitive. Some systems append to a markdown file. Others maintain a flat key-value store. None preserve the structure of how memories relate to each other: which correction superseded which earlier belief, which decision led to which outcome, which preference was refined through which sequence of interactions.<\/p>\n A memory chain is a linked sequence of related memory nodes stored in a relational database. Each node contains:<\/p>\n
\nDate:<\/strong> March 2026
\nVersion:<\/strong> 1.0<\/p>\n
\nExecutive Summary<\/h2>\n
\n
\nAbstract<\/h2>\n
\n1. Introduction<\/h2>\n
1.1 The Statelesness Problem<\/h3>\n
1.2 The Agent Amplification<\/h3>\n
1.3 The Compiled Context Alternative<\/h3>\n
\n
1.4 Model-Agnostic by Construction<\/h3>\n
\n
1.5 Local-First as Architectural Requirement<\/h3>\n
\n2. The Five Primitives<\/h2>\n
2.1 The Execution Cycle<\/h3>\n
\n
2.2 Why Five Primitives<\/h3>\n
\n
2.3 Processes Formalize the Cycle<\/h3>\n
\n
\n3. Process Definitions<\/h2>\n
3.1 Processes as Data, Not Prompts<\/h3>\n
process: fix_ci_failure\nversion: 3\ntrigger:\n type: event\n match:\n source: ci\n status: failure\n\nknowledge:\n - engineering.testing\n - project.ci_pipeline\n\ngates:\n - execution_context_exists\n - branch_clean\n\nsteps:\n - id: read_failure\n action: read_ci_log\n description: Identify the failing test and error message\n\n - id: locate_source\n action: find_relevant_code\n description: Find the source code responsible for the failure\n\n - id: diagnose\n action: analyze_failure\n description: Determine root cause of the failure\n\n - id: implement_fix\n action: write_code\n description: Implement the fix\n\n - id: verify\n action: run_tests\n description: Run the test suite to verify the fix\n\n - id: commit\n action: commit_and_push\n description: Commit the fix and push\n gates:\n - tests_pass\n<\/code><\/pre>\n3.2 Gates<\/h3>\n
3.3 Knowledge References<\/h3>\n
3.4 Process Inheritance and Composition<\/h3>\n
process: fix_ci_failure_with_notification\nversion: 1\nextends: fix_ci_failure\n\n# Inherits all steps, gates, knowledge from fix_ci_failure\n# Adds a notification step after commit\nsteps:\n - inherit: all\n - id: notify\n action: send_notification\n description: Notify the team that the CI failure has been fixed\n after: commit\n\n# Adds additional knowledge ref\nknowledge:\n - inherit: all\n - team.notification_preferences\n<\/code><\/pre>\n\n
before:<\/code> and after:<\/code> directives. The parent’s sequence is preserved; the child’s additions are spliced in.<\/li>\nabstract: true<\/code>, meaning it cannot be executed directly but serves as a template for concrete processes. This is the process equivalent of an abstract class.<\/li>\n<\/ul>\n# Abstract base process \u2014 cannot execute directly\nprocess: standard_code_change\nabstract: true\nversion: 1\n\ngates:\n - execution_context_exists\n - branch_clean\n\nknowledge:\n - engineering.pull_request\n - project.code_conventions\n\nsteps:\n - id: analyze\n action: analyze_requirements\n abstract: true # Must be overridden by child\n\n - id: implement\n action: write_code\n abstract: true # Must be overridden by child\n\n - id: verify\n action: run_tests\n\n - id: commit\n action: commit_and_push\n gates:\n - tests_pass\n<\/code><\/pre>\nprocess: fix_bug\nextends: standard_code_change\nversion: 1\n\nsteps:\n - id: analyze\n action: read_bug_report\n description: Identify root cause from bug report and logs\n\n - id: implement\n action: write_fix\n description: Implement the minimal fix\n\n---\n\nprocess: add_feature\nextends: standard_code_change\nversion: 1\n\nknowledge:\n - inherit: all\n - engineering.design_review\n\nsteps:\n - id: analyze\n action: read_feature_spec\n description: Understand the feature requirements\n\n - id: implement\n action: write_feature\n description: Implement the feature with tests\n<\/code><\/pre>\nstandard_code_change<\/code> defines the contract \u2014 what gates must pass, what knowledge is loaded, what sequence is followed. Concrete processes fill in the domain-specific behavior. The runtime doesn’t care whether it’s executing fix_bug<\/code> or add_feature<\/code> \u2014 it executes the linked process, step by step, through the same pipeline.<\/p>\n3.5 Process Interfaces<\/h3>\n
interface: code_change\nversion: 1\ndescription: Contract for any process that modifies code\n\nrequired_gates:\n - execution_context_exists\n - branch_clean\n\nrequired_steps:\n - id: analyze\n description: Understand what needs to change\n - id: implement\n description: Make the change\n - id: verify\n description: Verify the change works\n\nrequired_knowledge:\n - engineering.pull_request\n<\/code><\/pre>\nimplements: code_change<\/code> must provide concrete definitions for all required steps. The compiler verifies this at compile time \u2014 a process that claims to implement an interface but is missing a required step fails to compile.<\/p>\nprocess: fix_bug\nversion: 1\nimplements: code_change\n\n# Compiler verifies: analyze, implement, verify steps all present\n# Compiler verifies: execution_context_exists, branch_clean gates present\n# Compiler verifies: engineering.pull_request in knowledge refs\n\nsteps:\n - id: analyze\n action: read_bug_report\n description: Identify root cause from bug report and logs\n\n - id: implement\n action: write_fix\n description: Implement the minimal fix\n\n - id: verify\n action: run_tests\n description: Run the test suite\n<\/code><\/pre>\n\n
code_change<\/code> interface can be used where a code_change<\/code> is expected. The runtime can dynamically select which concrete process to execute based on the trigger event, the project context, or user preference.<\/li>\ndeploy_hotfix<\/code> process might implement both code_change<\/code> and deployment<\/code>, ensuring it meets the standards for both workflows.<\/li>\n<\/ul>\n3.6 The Process Compiler<\/h3>\n
\n
LinkedProcess<\/code> \u2014 an object where every reference is a direct pointer, not a name to be looked up at runtime. This is the process equivalent of a linked executable.<\/p>\n<\/li>\n\n
3.7 Versioning and Evolution<\/h3>\n
\n4. The Runtime<\/h2>\n
4.1 A Managed Runtime for Agent Processes<\/h3>\n
\n\n
\n \nJVM\/CLR Concept<\/th>\n CCR Equivalent<\/th>\n<\/tr>\n<\/thead>\n \n Class<\/td>\n ProcessDefinition (YAML source)<\/td>\n<\/tr>\n \n Class loader<\/td>\n ProcessLoaderEngine (YAML parse + validate)<\/td>\n<\/tr>\n \n Linker<\/td>\n ProcessLinkerEngine (resolve refs, bind gates)<\/td>\n<\/tr>\n \n Loaded class<\/td>\n LinkedProcess (all refs resolved)<\/td>\n<\/tr>\n \n Object instance<\/td>\n ExecutionRecord (a running\/completed execution)<\/td>\n<\/tr>\n \n Garbage collector<\/td>\n GCManager (generational, mark-sweep)<\/td>\n<\/tr>\n \n JIT cache<\/td>\n CacheManager (L1\/L2\/L3 tiered)<\/td>\n<\/tr>\n \n Class hierarchy<\/td>\n Process inheritance (extends, abstract)<\/td>\n<\/tr>\n \n Interface<\/td>\n Gate contracts + step action contracts<\/td>\n<\/tr>\n \n Bytecode verifier<\/td>\n Process validator (compile-time guarantees)<\/td>\n<\/tr>\n \n Debugger<\/td>\n Execution tracer + step inspector<\/td>\n<\/tr>\n \n ClassNotFoundException<\/td>\n ProcessLoadError<\/td>\n<\/tr>\n \n LinkageError<\/td>\n LinkError (unresolved ref)<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n 4.2 The Caching System<\/h3>\n
4.3 Generational Garbage Collection<\/h3>\n
\n
4.4 Observability<\/h3>\n
\n– Cache hit rates per tier (L1\/L2\/L3)
\n– GC pause times and collection counts per generation
\n– Compilation times (parse, validate, link, emit)
\n– Token usage per step and per process
\n– Execution duration per step
\n– Model selection decisions and latency
\n– Memory pressure and allocation rates<\/p>\n
\n– cortex trace <execution-id><\/code> \u2014 full execution trace
\n– cortex cache stats<\/code> \u2014 cache hit rates, sizes, eviction counts
\n– cortex gc stats<\/code> \u2014 generation sizes, collection history, promotion rates
\n– cortex process inspect <name><\/code> \u2014 compiled process details, inheritance chain
\n– cortex memory inspect <chain-id><\/code> \u2014 memory chain visualization<\/p>\n4.5 Bus Extensibility<\/h3>\n
\n
step.execute<\/code> events where action<\/code> matches your handler. The runtime doesn’t need to know about your handler \u2014 it publishes the event, your handler responds.<\/li>\ngate.evaluate<\/code> events where gate_name<\/code> matches your evaluator. Same pattern.<\/li>\nmodel.invoke<\/code> events. The model selection engine routes to your provider based on selection criteria.<\/li>\ntrace.*<\/code> events to build custom dashboards, export to external systems, or integrate with existing APM tools.<\/li>\n4.6 The Process IDE<\/h3>\n
\n5. Compiled Context Injection<\/h2>\n
5.1 The Compilation Pipeline<\/h3>\n
\n
5.2 The CTX Format<\/h3>\n
5.3 Per-Step Scoping<\/h3>\n
\n\n
\n \nStep<\/th>\n Knowledge Needed<\/th>\n Compiled Size<\/th>\n<\/tr>\n<\/thead>\n \n Read CI log<\/td>\n CI pipeline docs<\/td>\n 1,200 tokens<\/td>\n<\/tr>\n \n Locate source<\/td>\n Project structure<\/td>\n 2,400 tokens<\/td>\n<\/tr>\n \n Diagnose<\/td>\n Testing standards<\/td>\n 1,800 tokens<\/td>\n<\/tr>\n \n Implement fix<\/td>\n Code conventions<\/td>\n 3,200 tokens<\/td>\n<\/tr>\n \n Run tests<\/td>\n Test commands<\/td>\n 800 tokens<\/td>\n<\/tr>\n \n Commit<\/td>\n Git workflow<\/td>\n 600 tokens<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
\n6. Memory and Context Chains<\/h2>\n
6.1 The Memory Problem<\/h3>\n
6.2 Memory Chains<\/h3>\n
\n