Frontier Research

An irreducible, moving boundary

• The trade-off is irreducible. LLM-driven control flow is non-deterministic by construction, which is a problem for anything auditable or cost-bounded; code is predictable but brittle to novelty. Every real system must place each piece of logic on this axis.
• The boundary is an economic decision. Moving control flow into code has measured cost reductions up to about 3.5x in tokens with comparable accuracy and lower variance.
• The boundary moves as models improve. Instruction-following improved roughly 10x in a year (models that lost the thread at a few hundred simultaneous constraints in 2025 now hold thousands). Logic that had to be code last year can move into a prompt this year, so any static rule of thumb decays. For a research firm this is the crux: the question renews itself every few months.
• The evidence is genuinely contradictory. Mid-2026 produced peer-visible papers arguing opposite conclusions: one showing program-owned control flow dramatically beats LLM orchestration (86.8% in 15 steps vs a prior best of 80.4% in 100 steps on a GUI benchmark), another showing that for procedural tasks fitting the context window, in-context prompting matches or beats code orchestration frameworks. Both are right somewhere. Nobody has published the map of which tasks fall on which side.

What we are trying to find out

Exploration-mode questions: pursued to learn something, allowed to not pan out.

• The task-to-boundary map. Across a task taxonomy (procedural vs open-ended, short vs long horizon, stateless vs stateful, low vs high stakes), where does prompt-encoded logic match code-encoded logic, and where does each dominate? The deliverable is a decision rule backed by measured accuracy, cost, and variance.
• The crossover point. Hold a logic spec fixed, encode it once as a prompt and once as code, and measure how the reliability gap closes as model tiers climb. Nobody has measured the crossover as a function of logic complexity.
• Maintainability, measured. How expensive is a logic change in a prompt vs in code, especially under model upgrades? Metrics like edit-distance-to-fix and regression rate after a model swap are essentially unmeasured.
• Prompt-module interference. Instructions from one prompt-composed module bleed into others sharing context ("instruction bleed"); code isolates this by construction. How does interference scale with module count, and do isolation techniques eliminate it?
• When does prompt optimization pay? Programmatic optimizers (DSPy, GEPA) clearly beat hand-tuning, but benefits are conditional. A predictor of whether optimization will pay off before spending the rollouts would be genuinely useful and publishable.

What this work could become

Candidate development directions, not commitments or year-one programs.

• The decision framework. The evidence-backed answer to where should this specific piece of logic live, formalized as a methodology. It compounds through Stoa-owned experiments, public and licensed benchmarks, commissioned inputs with appropriate rights, and independently synthetic tasks.
• A measurement harness as core IP. Takes a logic spec, generates prompt-encoded and code-encoded implementations, and reports accuracy, cost, variance, and maintainability across model tiers. Useful internally, saleable, and a natural exploration-to-development graduation.
• Prompt-code boundary measurement. Because the frontier shifts every few months, client architectures silently rot in both directions. Re-measuring where each piece of logic should live is a repeatable analysis that can support consulting engagements when relevant.

The cleanest route to grounding

• The inverse parametric knowledge effect. A large cross-model study found ontological grounding helps inversely to how well the model’s training already covers the domain (roughly double the gain in low-resource domains, replicated across models). The ROI of a symbolic layer is highest exactly where the model is weakest: niche, proprietary, and non-English domains. This is a sharp targeting rule for where to apply the work.
• From validation gate to typed reasoning architecture. Production-scale systems now layer role, domain, and interaction ontologies, with output-side validation still the least-shipped layer, confirming it as the open frontier. Large-vendor moves (Microsoft’s ontology-based Fabric IQ layer) validate the direction commercially.

Three open questions

Exploration-mode questions: pursued to learn something, allowed to not pan out.

• Can a minimum viable ontology stack (structured outputs, a small SHACL shape set over the highest-risk entities, a repair loop) deliver measurable hallucination reduction without boiling the ocean on a full enterprise ontology?
• How well do LLM-assisted methods bootstrap ontology discovery in brownfield environments, where discovering the domain model is a larger project than enforcing it?
• Where is the rigidity threshold: at what point does over-constraining reject valid-but-novel outputs and turn the ontology into a bottleneck?

Two candidate directions

Candidate development directions, not commitments or year-one programs.

• An ontology-validated MCP tool pattern: server-side SHACL and reasoner checks on tool outputs before results reach the agent, keeping validation auditable.
• A targeting methodology built on the inverse-knowledge finding: identify the client domains where symbolic grounding pays most before proposing it.

What we deliberately avoid

Selected sources

• LLM-as-Code (arXiv 2606.15874); In-Context Prompting Obsoletes Agent Orchestration (arXiv 2604.27891); Instruction Bleed (arXiv 2606.26356)
• GEPA (ICLR 2026); Arize instruction-following benchmark and GEPA vs Prompt Learning comparison
• Anthropic, "Building Effective Agents"; 12-Factor Agents; CodeAct (ICML 2024)
• Ontology-Constrained Neural Reasoning in Enterprise Agentic Systems (arXiv 2604.00555)