Computational model

Type: kb/types/tag-readme.md · Status: current

What kind of "programs" LLM instructions are, and what programming-language concepts — scoping, homoiconicity, partial evaluation, typing — illuminate their behavior. Where learning-theory covers how systems learn and tags covers how knowledge bases are operated, this area covers the computational properties of the medium itself and the scheduling architecture that follows from context scarcity. This is a selective head; the published site appends the complete listing, and the scoped rg recipes recover full membership.

Foundations

• agentic-systems-interpret-underspecified-instructions — core framing: LLM instructions are distinguished by underspecified semantics and execution indeterminism
• context-efficiency-is-the-central-design-concern-in-agent-systems — why context is the scarce resource; cost has two dimensions (volume and complexity) that drive the mechanisms below
• bounded-context-orchestration-model — formalises orchestration as a symbolic scheduler driving bounded LLM calls through a select/call loop with explicit state update
• llm-context-is-a-homoiconic-medium — instructions and data share the same representation, enabling extensibility but removing structural guardrails
• llm-context-is-composed-without-scoping — context is flat concatenation with no scoping, producing dynamic scoping's pathologies; sub-agents are the one isolation mechanism

Scheduling & Orchestration

• agent orchestration occupies a multi-dimensional design space — scheduler placement, persistence, coordination form, guarantee, and return artifacts vary independently
• agent orchestration needs coordination guarantees, not just coordination channels — contamination, inconsistency, and amplification arise from different missing guarantees
• decomposition-heuristics-for-bounded-context-scheduling — practical rules: separate selection from joint reasoning, choose representations not subsets, save reusable intermediates
• llm-mediated-schedulers-are-a-degraded-variant-of-the-clean-model — when the scheduler lives in an LLM conversation it degrades; three recovery strategies
• session history should not be the default next context — stored history and next-context loading are separate decisions; select should decide what to load
• tool loop — the tool-loop area: loop exposure, hidden schedulers, and the observability problems of framework-owned loops (apparent success, semantic recovery)
• Claude Code dynamic workflows — shipped instance of the cluster: a harness exposing a returning agent() plus host-language composition beneath its frozen loop

Instruction Properties

• writing-styles-are-strategies-for-managing-underspecification — five observed context-file writing styles as strategies for narrowing the interpretation space
• programming-practices-apply-to-prompting — typing, testing, version control transfer to prompting with modified cost models
• unified-calling-conventions-enable-bidirectional-refactoring — calling conventions that let components move between neural and symbolic implementations

Error Correction & Reliability

Dual-tagged with LLM interpretation errors, which provides the broader error theory; these claims are about the scheduling architecture.

• scheduler-llm-separation-exploits-an-error-correction-asymmetry — symbolic operations are error-correctable through redundancy while LLM bookkeeping compounds errors silently
• specification-level separation recovers scoping before it recovers error correction — an intermediate regime where OpenProse-like DSLs recover frame isolation without hard-oracle bookkeeping

Tensions

• The homoiconic medium enables extensibility (ad hoc prompts, unified calling conventions) but requires explicit scoping disciplines precisely because there are no structural boundaries. The constraining gradient from instructions to scripts is one response — codifying imposes the structure the medium lacks.

Related Tags

• llm-interpretation-errors — error correction theory, oracle hardening, and reliability dimensions; explains why the scheduling architecture works
• tool-loop — the loop-exposure and hidden-scheduler cluster, including the observability failures of framework-owned loops
• learning-theory — how systems learn through constraining, codification, distillation; the computational model explains what kind of programs these mechanisms operate on
• tags — practical architecture applying these computational properties; frontloading and indirection cost are PL concepts applied to KB instructions

---

Agent Notes: - 2026-03-10: the Scheduling & Orchestration cluster plus the Multi-Agent Aggregation note form the core of a paper outline presenting the scheduling model for an academic audience.

Other tagged notes

• "Agent" is a useful technical convention, not a definition - A lightweight technical convention — an agent is a tool loop (prompt, capability surface, stop condition) — sidestepping the definitional debate in favor of a unit that organizes code
• Access burden and transformation burden are independent query dimensions - Queries have two independent difficulty axes — finding inputs (access) and producing the answer (transformation) — conflating them misroutes symbolic transformations through semantic processing
• Agent memory is a crosscutting concern, not a separable niche - Memory decomposes into storage (solved), retrieval/activation (context engineering), and learning (learning theory) — treating it as a standalone category hides that the hard problems are at the intersections
• Agent runtimes decompose into scheduler context engine and execution substrate - Practitioner runtime taxonomies converge on three separable components — scheduler, context engine, and execution substrate — because each solves a different class of model limitation
• Always-loaded context mechanisms in agent harnesses - Survey of always-loaded context mechanisms across agent harnesses — system prompt files, capability descriptions, memory, and configuration injection — cataloguing what each carries, how write policies differ, and where the gaps are
• Any symbolic program with LLM calls is a select/call program - Any program whose non-LLM steps are symbolic computation over explicit machine state K can be mechanically converted into the select/call loop with the same LLM calls in the same order
• Apparent success is an unreliable health signal in framework-owned tool loops - When framework-owned tool loops recover from broken tools via agent workarounds, final success stops being a reliable signal that the underlying scripts and workflows are healthy
• Codified scheduling patterns can turn tools into hidden schedulers - As agent behavior matures, deterministic next-step policies need explicit control logic; if the framework offers only tools, scheduling patterns end up there and the tools become hidden schedulers
• Context engineering - Definition — context engineering is the discipline of designing systems around bounded-context constraints; its operational core is routing, loading, scoping, and maintenance for each bounded call
• Conversation vs prompt refinement in agent-to-agent coordination - Conversation preserves the execution trace; prompt refinement compresses it into a clean handoff. The right choice depends on architecture and how much intermediate work should survive
• Directed reading - Definition - directed reading is reading selected material through an explicit task lens to produce a lens-shaped artifact or judgment
• LLM debugging starts with retry-versus-rewrite triage - The two-phenomena model makes the first LLM debugging question diagnostic — is the failure a bad execution of a good interpretation (retry) or a consistent choice of a bad interpretation (rewrite the spec)? — because the fixes differ and do not substitute
• LLM frameworks should keep the tool loop optional - Framework-owned tool loops package the common model/tool/retry pattern well, but strong frameworks keep the loop optional so applications can control state projection, branching, and re-entry
• LLM↔code boundaries are natural checkpoints - At each LLM↔code transition both semantic underspecification and execution indeterminism collapse simultaneously, making these boundaries natural places to anchor debugging, testing, and refactoring
• Orchestration strategies and run-state have opposite persistence economics - Inside a host-language scheduler, run-state K is task-specific so it has near-zero cross-task reuse value and should stay ephemeral, while select-strategies recur and are expensive to rediscover so they are the high-value promotion target — RLM discards both, losing the valuable half
• Pointer design tradeoffs in progressive disclosure - Design tradeoffs for progressive disclosure pointers — context-specificity vs precomputation cost vs reliability; fixed pointers (descriptions, abstracts) trade specificity for reliability and cheap reads, query-time pointers (re-rankers) trade cost for specificity, crafted pointers (link phrases) achieve highest density but depend on authoring discipline
• Progressive constraining commits only after patterns stabilize - Constraining via LLM code generation freezes a single projection of the spec in one shot, but progressive constraining observes behavior across many runs and commits only the interpretations that consistently emerge
• RLM has the model write ephemeral orchestrators over sub-agents - RLM packs orchestration over sub-agents into the tool-loop model by having the model write orchestrators in a REPL — elegant but ephemeral because the orchestrators are discarded after each run
• RLM, Tendril, and llm-do place symbolic work at different persistence boundaries - Compares RLM variants, Tendril, and llm-do as placements for symbolic work and interfaces: ephemeral REPL code, typed RLM combinators, workspace-local generated tools, and durable unified callables
• Semantic sub-goals that exceed one context window become scheduling problems - Some semantic subgoals exceed one context window, so they must be partitioned into smaller semantic judgments with symbolic collection, filtering, and staged summarization between them
• Silent disambiguation is the semantic analogue of tool fallback - When an agent silently resolves unacknowledged material ambiguity in a spec, final success hides that the contract failed to determine the path — an extension of the tool-fallback observability problem
• Solve low-degree-of-freedom subproblems first to avoid blocking better designs - Ordering heuristic for decomposition: commit first to decisions with the fewest viable options, then place flexible choices around them to preserve global optionality.
• Stateful tools recover control by becoming hidden schedulers - Granting the strongest stateful-tool escape hatch shows that recovered control comes from relocating the scheduler into an exceptional tool or runtime, not from the framework loop itself
• Subtasks that need different tools force loop exposure in agent frameworks - When decomposition creates child tasks with different tool surfaces, the parent must construct fresh calls for each child, so a framework-owned loop is no longer the right control surface
• The chat-history model trades context efficiency for implementation simplicity - Chat history persists because appending messages preserves information and avoids interface design, but that convenience trades away selective loading under bounded context
• The practical scheduler is the host language, not a reified select - The simplest practical orchestration library demotes the tool loop to a returning, per-call-parameterized function and lets ordinary host-language code play select and K — reifying K only when the run must outlive its process or outgrow its memory
• Topology, isolation, and verification form a causal chain for reliable agent scaling - Decomposition, scoping, and verification may form a strict dependency chain (topology → isolation → verification) rather than independent design choices — tests the simpler account that decomposition alone implies the other two
• Traditional debugging intuitions break when tool loops can recover semantically - Programmers trained on traditional software expect broken infrastructure to fail loudly; semantic recovery in agent tool loops violates that expectation, so successful outcomes can create false confidence during debugging and maintenance
• Under sub-agent decomposition, feasibility is the heaviest fork's net load - Once work is split across sub-agents, the per-window feasibility ceiling becomes per-agent — set by the heaviest fork's net load (what decomposition leaves on it after work is pushed across to siblings or up to the parent), which comes apart from the operation's summed cost