# A context and application layer for declarative, long-running agentic work Independent research · 2026 · Python, Rust, Dolt, FastAPI, Cytoscape.js, MCP, Claude Code hooks, Codex hooks, Docker · Role: Sole author ## Problem Coding agents can't compound tacit knowledge. They work within the bounds of a task, but generally without consideration for the purpose (telos) of that task as it aligns with a greater system. This manifests in 4 specific failure modes over time: Drift, Bloat, Sprawl, and Regressions -- each of which compounds at machine speed in a fully agentic environment. ## First principles - **'Truth' is stateful, and is separate from knowledge.** Humans know many things, not all of which are true. When humans make a decision, they pull from their relevant areas of knowledge applied to the current truth state in order to act -- this happens subconsciously. It's part of why you can work with someone for a long time and trust that saying 'Fix this bug' also carries all of the learned behavior around *how* to fix it the right way given the present circumstances. New information entering a system changes 'Truth', thus it is stateful. - **Humans trend towards declarative, rather than instructive, communication as knowledge compounds over time.** Also hardwired / learned behavior in our brain; it's an efficiency gain, and we are biologically incentivized towards efficiency to conserve energy. It's also cultural; you wouldn't patronize a senior engineer by telling him step-by-step how to do each task to succeed in his role. You give him an objective, and he works to achieve it. At our most efficient, humans can communicate with a look or a glance. Declarative prompting for agents requires the assembly and delivery of all of that learned context-relevant knowledge every time we communicate something. - **'Good' is subjective.** Take Coca-Cola and Liquid Death - both CPG beverage products, both companies with the goal to increase sales. Liquid Death has an album on Spotify that is entirely about how bad of a drink Liquid Death is. Amazing idea for viral content - yet that would be a shocking decision for a brand like Coca-Cola to make. Same output in a vacuum has different measures of correctness depending on the surrounding envrionment. - **An agent needs perspective.** Agents can't compound knowledge. An agent obviously needs task-specific information. What they also need is the smallest slice of the system's truth and future direction that could change *how* it executes that task. This is critical for any declarative instruction. Without that context, you get pyrrhic victories, which are a net system loss. - **Everything is measurable.** Math is a language humans created to describe reality. Systems are measurable in their entirety, at all scales. That means a bounded system in the present state has a quantifiable 'best' next decision for a given measurable outcome. For declarative agent work to succeed in such a system, a candidate change should run in an isolated copy of the whole system and be measured by its positive impact on established objectives (outputs of the system) before it is kept. It combines the principles of a Manufacturing assembly line (a la The Goal) and a chess engine: measure literally everything, identify the bottleneck, create distinct search-based proposals, prune them with checks, keep the best measured one, and maximize throughput while doing it. Humans default to Plan → Reduce → Choose → Execute. Agents, and compute, work best with Execute → Measure → Choose. ## Approach - **Prototype 1** (Python): an installable package with five Dolt databases (knowledge graph, sessions, telemetry, work, state), Claude Code and Codex hooks, a Docker candidate controller, and a live Observer dashboard. A “state bundle” seals one git commit together with exact Dolt revisions, and each candidate runs on its own branch. Prototyping containers and objectives ledger facilitated the "chess engine" analogy via ephemeral system clones and measurable impact on outcomes. First example of extensible ontology, measures for epistemic understanding, and rationale bindings for decisions. - **Prototype 2** (Rust and Python): Application layer introduced to package additional context with a submitted prompt in an interface. MCP tools replace most hooks, and context, action and effect checks run on every proposal. Parity substrate mimics LLM training pass with a loss calculation, dependency trace, correction, and replay (forward pass) of affected ontology subgraph. Each substrate gets an algebraic charter, for example State = K × D. - **Prototype 3** (Rust): In progress. Validating ideas with Experiment Harness before instructing build. Current focus is a derived truth state, inverting the parity process from the previous prototype. Truth is a first class object instead of a byproduct. The three figures below show Prototype 2's design for the context layer - how we facilitate a self-extending ontology. [![One Telos node informs and instructs: its description tells an agent what is true, its use tells the agent how to act, its owner's schema checks the result, and captured reads link each output to the use it followed](https://mikereese.dev/static/img/telos-ontology.png)](https://mikereese.dev/static/img/telos-ontology.png) [![One operation runs seven stages on its own branch: Operation, Checks (Context, Action, Effect), Validate by a person, Parity Check, Promote, Merge Check and Merge; a failed Parity Check invokes Parity, which returns a corrected delta to Promote](https://mikereese.dev/static/img/telos-operation.png)](https://mikereese.dev/static/img/telos-operation.png) [![Parity on the Definition example: the Parity Check finds two misses, the dependency trace runs back to the use of foundation:ontology, and the replay reruns the root operation and the Definition operation in containers on B1, returning one delta to Promote on B0](https://mikereese.dev/static/img/telos-parity.png)](https://mikereese.dev/static/img/telos-parity.png) ![The Telos Observer: which parts of the knowledge graph agents read, and how often](https://mikereese.dev/static/img/telos-observer.jpg) ## Skills I taught myself - **Mass Prototyping** -- Fan-out distinct proposal implementations with Bayesian confidence scores and measurable outcomes for promotion to the main system. - **Agent hooks and MCP tools** for Claude Code and Codex. Used to track efficiency, assert checks, and provide a measurable effectiveness metric to optimize. Byproduct of tracking agent sessions, turns, and tool use for given tasks is that we can create a dataset to post-train a model on. - **LLM Training and fine-tuning** -- Working through a course I created for myself with Jupyter Notebooks to learn the architecture and math behind model training and fine-tuning. Took the loss → backpropagation concept and applied it to a parity substrate in an earlier prototype; if we extend the ontology and previous items need to be updated, we can trace the dependency graph to the earlier knowledge and operation state, make the change there, and "replay" aka do a forward corrective pass to change the data state so that it is in parity. ## Result Once the application layer enforced tool use for agents to read Telos, the share of their reads that used it rose from 0.0 to 0.71 for a given declarative prompt. Build still in progress to date (09-2026), will publish more information as I continue to develop this.