Glages: Scientific and Practical Foundations

Glages begins with a strong proposition: reliable computational activity should not depend on a probabilistic system reconstructing stable operational meaning during every execution.

That proposition requires evidence.

It would be weak to justify Glages only by saying that current agents sometimes make mistakes, or that formal models appear more orderly than free-form reasoning. The important question is whether independent research and real systems already provide support for the architectural principles on which Glages is built.

They do.

Across formal planning, neuro-symbolic AI, executable knowledge bases, compiled AI, agent reliability research, deterministic policy gates, enterprise ontologies, and production agent systems, a consistent pattern is visible:

Use probabilistic models where interpretation and construction benefit from flexibility. Move stable knowledge, constraints, policy, validation, and repeatable execution into explicit structures that can be checked independently.

No single project establishes the Glages architecture.

Taken together, however, these lines of work provide a scientific and practical foundation for it.

Glages builds on that foundation by treating the systematic production of reusable formal models as the central technology.

1. The Foundation Predates Modern LLMs

Formalization did not begin with generative AI.

Computer science has long separated a specification from the mechanism that executes it. Type systems constrain legal programs. Formal logic expresses propositions and relationships. State machines define valid transitions. Classical planners search over explicit action models. Model checking evaluates whether systems satisfy specified properties. Static analyzers reject structures that violate rules before execution.

These methods differ in purpose and representation, but they share a principle important to Glages:

Important operational meaning should exist in a form that can be checked independently of the mechanism proposing or performing an action.

Modern LLMs do not invalidate this principle.

They change the economics of producing the structures to which the principle can be applied.

The relevant question is therefore not whether formal structure is a new invention.

It is whether AI can make the construction, correction, and reuse of formal structure practical at a much larger scale.

Recent work provides increasing evidence that it can.

2. LLMs Already Serve as Formalizers

One of the clearest precedents is the use of language models as interfaces to formal planning.

LLM+P translates a natural-language planning problem into PDDL, delegates solution generation to a classical planner, and converts the result back to natural language.[1] The architecture assigns interpretation to the LLM and planning correctness to a formal planning system.

Guan et al. go further. Their system uses an LLM to construct an explicit PDDL world model, accepts corrective feedback from validators and humans, and then uses the corrected domain model repeatedly with sound planners.[2] Their motivation is especially relevant: direct LLM planning is unreliable, while correcting the domain model once can improve many later plans.

This is already close to one Glages principle:

source material
→ candidate formal model
→ correction and verification
→ reusable model
→ repeated use

The model is not merely a prompt.

It becomes an explicit artifact that outlives the generation step.

3. ATA Separates Knowledge Construction From Decision Execution

ATA provides a direct neuro-symbolic example.

The architecture divides work into offline knowledge ingestion and online task processing.[3]

During offline ingestion, an LLM translates an informal problem specification into a formal symbolic knowledge base. That knowledge base can then be reviewed and corrected. During online processing, each new input is encoded in the same formal language, and a symbolic decision engine derives the result.

The significance is architectural.

The LLM does not remain the final authority for the recurring decision process.

A formal artifact produced with AI assistance becomes the persistent knowledge structure against which new cases are evaluated.

ATA reports that a human-verified knowledge base can outperform larger end-to-end reasoning models while providing deterministic behavior and greater stability.[3]

This supports several Glages principles at once:

• model construction and model use can be separated;
• LLM output can be treated as a candidate rather than an authority;
• a corrected formal artifact can be reused across many cases;
• deterministic reasoning can carry stable decision logic after formalization.

ATA does not implement the Glages Model Factory.

It demonstrates that a key transformation assumed by Glages is technically meaningful: informal knowledge can be converted into a verified symbolic representation and then used independently of end-to-end LLM reasoning.

4. ARc Shows Formal Policies as Durable Verification Artifacts

A Neurosymbolic Approach to Natural Language Formalization and Verification, referred to here as ARc, provides another direct foundation.[4]

The system uses LLMs, optionally with human guidance, to formalize natural-language policies. Verification then operates over logical artifacts rather than asking an LLM to judge the policy text directly.

The authors report soundness above 99 percent on their benchmarks.[4] More important than the number is the design principle: the formal policy becomes a persistent artifact supporting later verification.

This is closely aligned with the Glages distinction between source material and model.

A policy document is evidence.

A machine-checkable policy representation can become part of an operational model.

The transformation creates an asset that can be tested and reused.

5. Kintsugi Makes the Deployed Artifact Explicit

Kintsugi makes the separation even clearer.[5]

The system represents task-level policy knowledge as a typed executable knowledge base containing predicates, operators, policy schemas, monitors, recovery rules, experience records, and goals. Failures from previous rollouts are used to propose localized edits.

The critical part is acceptance.

A deterministic verification gate admits an edit only when the candidate passes structural and behavioral checks.

After acceptance, inference uses deterministic symbolic execution with zero LLM calls.[5]

This provides a particularly strong foundation for the Glages idea of accumulated model value.

execution
→ observed failure
→ candidate correction
→ deterministic verification
→ accepted knowledge-base change
→ stronger future execution

The deployed policy is therefore carried by the verified knowledge structure, not by an LLM repeatedly reconstructing policy from context.

That resembles Experience Capitalization in computational form: experience changes the persistent model rather than disappearing after the episode.

Glages generalizes this principle beyond one policy-learning architecture. A model factory should accumulate verified structures, tests, corrections, reusable relationships, and validated cases so that later models begin from a stronger foundation.

6. Compiled AI Establishes the Production-Execution Asymmetry

Compiled AI gives this separation a strong systems and economic interpretation.[6]

The paper studies a paradigm in which LLMs generate executable code artifacts during a compilation phase. After validation, workflows execute deterministically without further model invocation.

On its function-calling benchmark, the paper reports 96 percent task completion, zero execution tokens, a break-even point at roughly 17 transactions, and a 57-fold token reduction at 1,000 transactions relative to repeated runtime inference.[6]

The exact numbers belong to the evaluated tasks and should not be generalized automatically.

The more important result is the asymmetry they demonstrate:

Generating stable business logic may benefit from expensive probabilistic reasoning. Reusing stable business logic does not require paying for the same reasoning again.

This is a central economic foundation for Glages.

The Model Factory can use powerful AI during production where interpretation, comparison, candidate generation, and repair are genuinely valuable.

The resulting model can then move stable meaning into a reusable artifact.

That changes both reliability and economics.

7. PlanCompiler Shows the Value of Typed Planning and Static Validation

PlanCompiler provides a related but distinct result.[7]

Instead of allowing an LLM to generate and execute arbitrary multi-step code, the system requires the model to create a typed JSON plan over a fixed registry of primitives. The plan is statically validated, and only validated plans are compiled into executable Python.

On its 300-task benchmark, PlanCompiler reports 278 successes, compared with 202 for a GPT-4.1 free-form code-generation baseline and 187 for a Claude Sonnet baseline, while also reporting substantially lower planning cost.[7]

Again, the significance is not that this benchmark proves a universal advantage.

It demonstrates that constraining the planning problem to an explicit typed space, validating the candidate independently, and separating planning from deterministic execution can materially improve results in structured workflow tasks.

That supports the Glages principle that an LLM should operate inside a defined model space rather than silently expand the operational world during execution.

8. POLARIS Applies Typed and Governed Structure to Back-Office Automation

POLARIS moves the same direction into enterprise back-office work.[8]

The system treats automation as typed plan synthesis and validated execution over agents. It uses type-checked DAGs, validator-gated checks, bounded repair, and compiled policy guardrails that can block or route side effects before they occur.

This is important because it addresses exactly the class of environment in which free-form agent behavior is often presented as automation.

POLARIS does not claim that an agent should simply receive access to enterprise systems and infer the process.

It introduces explicit typed structure and policy controls around the execution path.

That is consistent with a broader observation:

As agentic systems move from demonstration to operational use, important parts of the activity tend to migrate out of free-form reasoning and into explicit contracts, policies, types, and execution controls.

Glages treats that migration as a signal that the activity itself should be modeled systematically.

9. Deterministic Gates Prevent Failures That the Agent Does Not See

Reason Less, Verify More isolates a particularly important failure mode.[9]

In the evaluated tool-using agents, a policy-permissive tool can successfully execute a syntactically valid call even when the state transition violates domain policy. The tool reports success, and the agent may also report success, while the system has entered the wrong state.

The authors call this a silent wrong-state failure.

In their airline benchmark, 78 percent of observed failures for the budget agent were of this type. Adding deterministic read-only gates before state-changing actions raised full-benchmark success from 29.6 percent to 42.0 percent, with a similar improvement reproduced on a disjoint seed set.[9]

The lesson maps directly to a Glages distinction:

tool call is technically valid
≠
state transition is valid in the activity

The required policy relation must exist outside the agent's self-assessment.

This is one reason Glages distinguishes between an execution mechanism and the model that determines which changes are permitted.

10. GuardianAgentBench Finds Structural Guardrails Stronger Than Prompt-Level Defense

GuardianAgentBench evaluates 580 scenarios across six domains and three production-ready frameworks.[10]

The strongest evaluated configuration reached 74.8 percent overall accuracy. The study also reports that execution-time guardrails recovered 19.9 percent of failures at a 0.5 percent false-positive rate and consistently outperformed system-prompt-based defenses across the tested models.[10]

This matters for the location of control.

The benchmark should also be read with an affiliation caveat: seven of its eight authors are affiliated with Vectara, and Vectara is one of the three production frameworks evaluated in the study.[10] This does not invalidate the reported results, but it is relevant context when weighing the evidence and is one reason the argument here does not rely on this benchmark alone.

If critical rules exist only in the prompt, the same probabilistic mechanism that is interpreting the task is also carrying the control structure.

Execution-time structural intervention moves part of that responsibility outside the model.

Glages extends the same separation.

The formal model should define stable operational boundaries independently of the LLM that may operate inside them.

11. Production Practice Already Limits Agent Autonomy

The strongest argument for formal structure would be incomplete without evidence from real deployments.

Measuring Agents in Production surveyed 306 practitioners, conducted 20 in-depth case studies, and covered 26 domains.[11]

The reported pattern is notably conservative:

• 68 percent of deployed agents execute at most 10 steps before human intervention;
• 70 percent rely on prompting off-the-shelf models rather than weight tuning;
• 74 percent depend primarily on human evaluation;
• reliability is reported as the top development challenge.[11]

This does not prove that short-horizon systems are always better.

It shows that production practice already trades theoretical autonomy for controllability.

That is important for Glages because the project does not begin from the assumption that more autonomy is automatically the goal.

The more fundamental question is what has been defined well enough to execute without reconstruction.

12. Failure Research Locates Problems in Specification and Coordination

Why Do Multi-Agent LLM Systems Fail? studies failures across popular multi-agent frameworks and develops a taxonomy covering specification and system design failures, inter-agent misalignment, and task verification and termination.[12]

The study is useful because it moves the discussion away from the simplistic explanation that agents fail only because models are not yet intelligent enough.

Failures can arise from how the system is specified and coordinated.

That is structurally important.

If the system does not have an explicit model of required facts, relationships, actions, results, and boundaries, a more capable LLM still inherits an underspecified operational world.

Glages addresses this at the model layer rather than treating every failure as a reason to increase model intelligence.

13. Ontology-Constrained Neural Reasoning Demonstrates Asymmetric Coupling

Ontology-Constrained Neural Reasoning in Enterprise Agentic Systems introduces what the authors call asymmetric neurosymbolic coupling.[13]

A three-layer ontology covering Role, Domain, and Interaction provides formal semantic grounding for enterprise agents. Symbolic structure constrains context assembly, tool discovery, and governance thresholds, with additional mechanisms proposed for output-side validation.

The current v5 paper reports a controlled experiment of 1,800 runs across five industries and three LLMs - Claude Sonnet 4, Qwen 2.5 72B, and Gemma 4 26B - with 600 runs per model. It also describes a production system serving 22 industry verticals with more than 650 agents.[13]

The phrase asymmetric coupling is useful because it describes a relationship important to Glages.

The LLM and the formal model do not have the same authority.

The LLM provides probabilistic capability.

The formal structure defines stable domain meaning and constraints.

Glages adopts this asymmetry more broadly: the model remains the source of permitted operational meaning, while AI is one mechanism used to construct or operate within that model.

14. Wix Shows Deterministic Executability Gating at Production Scale

A recent production study from Wix provides another practical example.[14]

Their customer-care assistant first uses semantic matching to identify potentially relevant skills, then applies a deterministic executability gate based on authoritative account state, and only then allows the LLM to choose among the remaining skills.

In a post-launch analysis of 756,600 messages, the gate removed 59.4 percent of skill-message pairs remaining after semantic matching. In a counterfactual replay of 1,000 risk-enriched conversations, the model selected a production-blocked skill in 7.8 percent of conversations when all skills were exposed.[14]

The architecture is important:

probabilistic relevance
→ deterministic executability
→ probabilistic choice among valid candidates

The agent does not receive every semantically plausible action and then get asked to behave responsibly.

The system determines first which actions are executable in the current state.

That is directly consistent with the Glages principle of narrowing the agent's world before the agent acts.

15. Palantir Demonstrates the Value of an Operational Model

The same need for explicit structure appears in major enterprise platforms.

Palantir describes its Ontology as an operational layer combining data, logic, action, and security.[15] Object types and links describe the semantic structure, while action types and functions define ways in which the operational world can change.[16]

Palantir also describes the Ontology as a shared operational foundation that can be used by humans and agents.[16]

The significance for Glages is not that the Palantir Ontology is the same product.

It is evidence that a large enterprise platform has found substantial value in representing the organization through an explicit operational model rather than exposing only databases, APIs, and free-form instructions.

Glages takes a different product position.

The central asset is not one company's ontology platform. It is the capability to produce reusable formal models that can be applied across organizations and computational environments.

16. Microsoft Fabric IQ Moves Toward a Governed Shared Business Model

Microsoft Fabric IQ provides a second large-platform signal.

Microsoft describes its Ontology as a scaled, secure, governed shared business model used across teams, agents, and workflows.[17] The Fabric IQ overview says that Ontology defines core business entities, relationships, properties, rules, and actions, while agents use this structure to understand available actions and how to invoke them.[18]

The agent-integration documentation emphasizes that agents reason over entity types and relationships rather than only raw tables and columns, and that shared definitions, rules, metrics, provenance, and access controls provide consistent governed context.[19]

Again, this is not Glages.

It confirms the practical need for a layer of explicit business meaning outside the LLM.

The existence of that need strengthens the case for a technology whose purpose is to produce and maintain formal models systematically.

17. Business Process Research Is Making Process Structure Explicit for Agentic Systems

The most direct adjacent literature comes from Business Process Management itself. A closer reading shows that this literature is not one unified endorsement of model-first automation. It contains at least two distinct tendencies: one strengthens explicit process specifications and formal process knowledge, while another intentionally increases runtime autonomy beyond fully predesigned process flows. Both are relevant to Glages, but for different reasons.

The 2026 Agentic Business Process Management: A Research Manifesto is the strongest conceptual source.[20] It defines an APM agent as an autonomous execution entity whose behavior is framed so that it remains process-aware and aligned with process goals. The frame is not merely descriptive context. The paper defines it as a set of rules, restrictions, regulations, goals, norms, and process logic that establishes the boundaries within which agents may act. It distinguishes operational requirements from normative requirements such as obligations, prohibitions, and permissions, and explicitly identifies formal logic-based approaches as a possible foundation for enforcing an agent's operational boundary.

The Manifesto is also notable for how it treats process knowledge over time. It distinguishes short-term adaptation, which changes only a particular execution, from long-term evolution, in which repeated evidence can justify persistent changes to the process logic, model, or policy. Those changes affect future process instances and become part of the agent's frame.[20] This is closely related to the Glages idea that verified experience should improve a persistent model rather than disappear after one execution.

At the same time, the Manifesto remains fundamentally agent-centric. Its primary object is the autonomous process-aware agent, and it deliberately leaves the concrete realization of framing open. The frame may be implemented through orchestration, shared memory, formal rules, or other mechanisms. It does not propose a general technology for producing reusable process or domain models. That boundary is important: the Manifesto provides strong support for the need for explicit process-aware constraints, but not for the Glages Model Factory itself.

Azarijafari, Mich, and Missikoff's AGO framework is technically closer to the model side of the Glages argument.[22] AGO begins not with a workflow diagram but with three formal entity classes: Objects, Goals, and Agents. Business objects represent the evolving state of affairs; goals define desired states; agents are active elements whose skills transform trigger sets of objects into delivery sets. The resulting Business Process Knowledge Base (BPKB) imposes consistency conditions, including goal reachability and satisfiability and consistency between trigger sets, delivery sets, goals, and agents.

A particularly important feature is that the workflow is derived from the knowledge base rather than supplied as the primary model. AGO constructs precedence relations from the formally defined entities and reconstructs end-to-end workflow paths bottom-up. The paper claims soundness and completeness of those derived paths under its formalization.[22]

This makes AGO a useful adjacent precedent for Glages because it treats the process diagram as a consequence of a deeper formal knowledge structure rather than as the foundational artifact. The difference is equally important. AGO is a compact declarative methodology centered on three entity types and is presented as an analyst-driven modeling framework. It does not address automated extraction from heterogeneous documentary sources, model production at scale, reusable cross-domain model libraries, composition, specialization, or independent machine verification of AI-generated candidate models. In other words, AGO demonstrates that a business process can be reconstructed from a formal knowledge base, while Glages asks how such formal knowledge bases can themselves be produced systematically.

Dumas, Milani, and Chapela-Campa's Agentic Business Process Management Systems should be treated somewhat differently.[21] The paper explicitly argues for a shift from design-driven process management toward data-driven management based on process mining. Its A-BPMS architecture combines data, process intelligence, action, orchestration, and conversational layers. Agents sense process state, use predictive and prescriptive process analytics, and may adapt execution beyond fully predesigned rules, models, or scripts.

This paper therefore does not directly support the strongest Glages claim that stable activity structure should be formalized before execution. In fact, it deliberately preserves a larger role for runtime autonomy. Its relevance is that even this autonomy-oriented architecture still depends on process models, event logs, process-state information, explicit constraints and boundaries, conformance checking, and a process-intelligence layer. It shows that the agentic BPM community is not eliminating process structure; it is debating how much should be predefined and how much should remain adaptive.

A fourth paper found during this deeper review is even more directly relevant: Formal Foundations of Agentic Business Process Management by De Giacomo, Kampik, Kirchdorfer, Montali, and Weinhuber.[25] It states explicitly that agentic BPM systems are built around a process specification, then augments that specification with agent goals and formal guardrails. The paper models a process specification as a set of admissible traces, defines agent strategies formally, and studies which strategies remain admissible under process constraints and goal satisfaction. This provides a mathematical version of the same architectural separation seen elsewhere in this review: autonomous decision-making is permitted, but only inside an explicitly specified operational space.

Taken together, the BPM literature supports a more precise conclusion than the earlier version of this section suggested:

Business Process Management is not converging on one single agent architecture. It is converging on the need to make process state, goals, constraints, and operational boundaries explicit enough that autonomy can be analyzed, governed, or formally constrained.

For Glages, this is important foundational evidence. The remaining step is not merely to give agents process awareness. It is to develop a production technology for creating, verifying, reusing, composing, specializing, and maintaining the formal models that provide that awareness.

18. RAG and Knowledge Graphs Solve a Different Part of the Problem

A common objection is that retrieval-augmented generation or knowledge graphs already provide the required grounding layer.

They solve important problems, but not the same one.

RAG improves access to relevant source material. It can retrieve current policies, records, documentation, and evidence for the model to interpret. A knowledge graph can make entities and relationships explicit and support structured traversal or inference.

Neither automatically defines a complete executable activity.

The Ontology-Constrained Neural Reasoning paper is useful here because it compares RAG and ontology grounding directly. In its experiment, well-curated RAG was competitive with ontology injection on several metrics, and ontology did not uniformly outperform RAG.[13] The authors nevertheless distinguish ontologies categorically because they can encode structural constraints, composable relationships, machine-readable definitions, workflow enforcement, and formal verifiability in ways a document-chunk retrieval pipeline does not.[13]

Glages makes a related but broader distinction:

RAG
provides relevant evidence

knowledge graphs and ontologies
provide explicit semantic structure

Glages model
must additionally define the formal structure required for its computational purpose,
including processes, required facts, conditions, permitted actions, results, and boundaries

These layers can be used together.

A Glages Model Factory may use retrieval as a source mechanism and graphs or ontologies as source material or supporting representations. The claim is not that they are unnecessary. It is that retrieval and representation alone do not solve the complete model-production problem.

19. The Specification Problem Is Still Open

The same studies that support the Glages direction also expose its hardest unresolved problem.

ATA provides a quantitative example. On the travel-insurance task, the automatically formalized knowledge base produced 72.94 percent accuracy. The authors then manually compared the natural-language rules with their formalization and corrected missing clauses, missing predicates, and ambiguous predicate definitions. Accuracy increased to 87.17 percent, a gain of 14.23 percentage points.[3]

Compiled AI states the issue even more explicitly: its deterministic runtime assumes that users can specify the workflow correctly, and the paper says that the specification problem remains fundamental and often requires iterative refinement.[6]

This is not a side limitation.

It is central to the Glages research problem.

formal execution can be deterministic
while
formal model production can still be wrong

A Model Factory therefore needs more than an LLM that translates documents into formal syntax. It needs independent verification, comparison against multiple sources and cases, explicit unresolved states, tests, correction mechanisms, and a way to prevent an uncertain candidate from becoming operational truth.

The current evidence supports the value of the artifact after verification more strongly than it supports fully automatic creation of a correct artifact.

Glages should make that boundary explicit.

20. DSPy Is an Important Predecessor of the Compilation Line

The compilation idea also has an earlier LLM-specific predecessor.

DSPy introduced a programming model in which LM pipelines are expressed through declarative modules and a compiler optimizes the pipeline against a metric.[23] It was an important step away from manually engineered prompt strings toward a distinct programming and compilation layer around probabilistic models.

DSPy is not a formal-model system. Its compiled artifacts still include runtime LM behavior, and its objective is optimization of LM pipelines rather than creation of an independent model of activity.

Its importance here is historical.

Compiled AI explicitly situates itself in a line that includes DSPy and LLM+P.[6] The progression is instructive:

prompt engineering
→ declarative LM programming and compilation
→ formal planning representations
→ compiled deterministic workflows
→ persistent executable knowledge structures

Glages extends the question from compiling an LM program to producing the reusable formal model on which many programs and execution mechanisms may depend.

21. The Bitter Lesson Defines a Serious Counterargument

A foundational proposal centered on explicit structure must address Richard Sutton's Bitter Lesson.[24]

Sutton's argument is that general methods based on search and learning have repeatedly displaced approaches that encode large amounts of human-designed domain knowledge, because general methods benefit more effectively from growing computation.[24]

Taken superficially, this could appear to argue against Glages.

That interpretation would be mistaken for two reasons.

First, Glages does not propose replacing scalable learning with manual expert encoding. Learned models are expected to play a major role in recognition, comparison, candidate construction, formalization, repair, and model production.

Second, Glages targets information with a different requirement: stable operational meaning that must be inspectable, verifiable, reusable, or enforceable independently of a particular inference run.

The relevant question is empirical:

Which knowledge should remain learned and reconstructed dynamically, and which knowledge should be distilled into explicit structure once it becomes stable enough to verify and reuse?

Glages does not assume that everything should become formal.

A successful Model Factory must be able to leave uncertainty outside the model, preserve explicit stopping boundaries, and use probabilistic mechanisms where formalization would be premature or counterproductive.

The Bitter Lesson is therefore not something to dismiss. It establishes a design constraint: Glages must use scalable learning to produce and evolve models rather than becoming a hand-engineered knowledge system that cannot benefit from increasing AI capability.

22. The Evidence Points to a Common Architecture

These systems come from different communities and solve different problems.

They should not be collapsed into one category.

Yet several recurring principles appear across them.

Principle 1: Use LLMs to construct candidates, not as the only source of truth

LLM+P, explicit PDDL world-model construction, ATA, ARc, Kintsugi, Compiled AI, and PlanCompiler all separate probabilistic generation from a more explicit artifact or validator.[1][2][3][4][5][6][7]

Principle 2: Correct a reusable structure instead of correcting every execution

Guan et al., ATA, ARc, and Kintsugi make corrections persistent by placing them in a formal model or knowledge base rather than only in a conversation.[2][3][4][5]

Principle 3: Stable policy and state constraints belong outside unconstrained LLM reasoning

POLARIS, Reason Less Verify More, GuardianAgentBench, ontology-constrained reasoning, and Wix executability gating all introduce control structures outside free-form model inference.[8][9][10][13][14]

Principle 4: Repeated execution does not need repeated reconstruction

Compiled AI and Kintsugi demonstrate this explicitly through deterministic post-construction execution.[5][6]

Principle 5: Operational AI benefits from a shared semantic and action model

Palantir and Microsoft provide industrial examples of explicit operational or governed business models serving both software and agents.[15][17][18]

These principles do not prove every part of Glages.

They make its starting assumptions substantially less speculative.

23. What the Existing Work Does Not Yet Provide

If so much of the foundation already exists, what remains for Glages?

The existing work is fragmented by purpose.

One system formalizes policies.

Another compiles workflows.

Another repairs an executable knowledge base.

Another grounds agents in an ontology.

Another gates tool calls.

Another models one enterprise inside one platform.

The common missing production question is:

How can reusable formal models themselves be produced systematically across domains?

Glages places that question at the center.

Its required capabilities include:

knowledge and source material
→ recognition and resolution
→ candidate model
→ formal representation
→ verification
→ reusable model
→ composition
→ specialization
→ application
→ verified experience
→ model improvement

The long-term asset is therefore not one policy, one workflow, one ontology, or one business-domain model.

It is the factory and the growing model library.

24. The Scientific Claim Should Remain Modest and Precise

The evidence reviewed here supports the architectural direction of Glages.

It does not prove that a general-purpose Model Factory can already construct every required model automatically.

It does not prove that every operational domain can be completely formalized.

It does not prove that deterministic execution is appropriate for every part of intelligent activity.

Those are not necessary claims.

The specification problem described above is especially important: current evidence shows that formal artifacts can provide strong benefits once they are correct, while reliable large-scale production of those artifacts remains an open technical problem.

The stronger and more defensible claim is:

A substantial body of recent work already demonstrates that LLM-generated or LLM-assisted formal artifacts can be verified, reused, executed symbolically or deterministically, and used to constrain agent behavior more reliably than leaving the same structure entirely inside free-form runtime reasoning.

Glages builds directly on that demonstrated direction.

Its research and engineering challenge is to make the production, verification, composition, specialization, maintenance, and reuse of formal models systematic.

25. From Foundation to Model Factory

Modern AI created the conditions for Glages in two ways.

First, it exposed the limits of asking probabilistic systems to carry all operational meaning at runtime.

Second, it created a new capability for reading and restructuring the enormous body of human knowledge that was previously too expensive to formalize at scale.

The research reviewed here shows intermediate forms of the same transition:

language
→ formal planning representation

policy text
→ logical policy artifact

experience
→ repaired executable knowledge base

business logic
→ compiled deterministic code

agent proposal
→ deterministic policy gate

enterprise data
→ governed operational ontology

Glages treats these not as isolated tricks, but as evidence of a broader production opportunity.

Accumulated knowledge can increasingly be converted into explicit computational structure.

Formal methods can verify parts of that structure.

Learned models can help produce and repair it.

Execution systems can use it without reconstructing it on every run.

Organizations can connect their own systems to common models.

Verified experience can improve the shared asset.

That is the scientific and practical foundation of the Glages Model Factory.

The proposed next step is to turn these principles into a systematic technology for producing models themselves.

References

1. Liu, B., Jiang, Y., Zhang, X., Liu, Q., Zhang, S., Biswas, J., and Stone, P. "LLM+P: Empowering Large Language Models with Optimal Planning Proficiency." arXiv:2304.11477, 2023. https://arxiv.org/abs/2304.11477
2. Guan, L., Valmeekam, K., Sreedharan, S., and Kambhampati, S. "Leveraging Pre-trained Large Language Models to Construct and Utilize World Models for Model-based Task Planning." arXiv:2305.14909, 2023. https://arxiv.org/abs/2305.14909
3. Peer, D., and Stabinger, S. "ATA: A Neuro-Symbolic Approach to Implement Autonomous and Trustworthy Agents." arXiv:2510.16381, 2025. https://arxiv.org/abs/2510.16381
4. Bayless, S., et al. "A Neurosymbolic Approach to Natural Language Formalization and Verification." arXiv:2511.09008, 2025. https://arxiv.org/abs/2511.09008
5. Cao, T., Deng, Y., Shindo, H., Delfosse, Q., Wen, L., Wang, S., Blüml, J., Tauchmann, C., and Kersting, K. "Kintsugi: Learning Policies by Repairing Executable Knowledge Bases." arXiv:2605.09487, 2026. https://arxiv.org/abs/2605.09487
6. Trooskens, G., et al. "Compiled AI: Deterministic Code Generation for LLM-Based Workflow Automation." arXiv:2604.05150, 2026. https://arxiv.org/abs/2604.05150
7. Harikumar, P. "PlanCompiler: A Deterministic Compilation Architecture for Structured Multi-Step LLM Pipelines." arXiv:2604.13092, 2026. https://arxiv.org/abs/2604.13092
8. Moslemi, Z., Koneru, K., Lee, Y.-T., Kumar, S., and Radhakrishnan, R. "POLARIS: Typed Planning and Governed Execution for Agentic AI in Back-Office Automation." arXiv:2601.11816, 2026. https://arxiv.org/abs/2601.11816
9. Reddy, V., Challaram, S. R., and Basu, A. "Reason Less, Verify More: Deterministic Gates Recover a Silent Policy-Violation Failure Mode in Tool-Using LLM Agents." arXiv:2607.07405, 2026. https://arxiv.org/abs/2607.07405
10. Naik, V. I., Xu, C., Dong, D., Hassan, H., Pradhan, A., Mendelevitch, O., Shafat, T., and Irshad, H. "GuardianAgentBench: Where Agents Fail and How to Guard Them." arXiv:2607.20982, 2026. https://arxiv.org/abs/2607.20982
11. Pan, M. Z., et al. "Measuring Agents in Production." arXiv:2512.04123, 2025, revised 2026. https://arxiv.org/abs/2512.04123
12. Cemri, M., et al. "Why Do Multi-Agent LLM Systems Fail?" arXiv:2503.13657, 2025. https://arxiv.org/abs/2503.13657
13. Tuan, T. L., and Sanyal, A. "Ontology-Constrained Neural Reasoning in Enterprise Agentic Systems: A Neurosymbolic Architecture for Domain-Grounded AI Agents." arXiv:2604.00555v5, 2026. https://arxiv.org/abs/2604.00555v5
14. Ashkenazi, O., Kloz, V., and Ulianchenko, M. "Don't Offer What Can't Be Done: Deterministic Executability Gating for LLM Skill Selection at Scale." arXiv:2608.01050, 2026. https://arxiv.org/abs/2608.01050
15. Palantir. "The Ontology system." https://palantir.com/docs/foundry/architecture-center/ontology-system/
16. Palantir. "Why create an Ontology?" https://palantir.com/docs/foundry/ontology/why-ontology/
17. Microsoft. "What Is Ontology (Preview)? - Microsoft Fabric." https://learn.microsoft.com/en-us/fabric/iq/ontology/overview
18. Microsoft. "What is Fabric IQ?" https://learn.microsoft.com/en-us/fabric/iq/overview
19. Microsoft. "Agent Integration Options for Ontology (Preview)." https://learn.microsoft.com/en-us/fabric/iq/ontology/concepts-agent-integration
20. Calvanese, D., et al. "Agentic Business Process Management: A Research Manifesto." arXiv:2603.18916, 2026. https://arxiv.org/abs/2603.18916
21. Dumas, M., Milani, F., and Chapela-Campa, D. "Agentic Business Process Management Systems." arXiv:2601.18833, 2026. https://arxiv.org/abs/2601.18833
22. Azarijafari, M., Mich, L., and Missikoff, M. "A Formal Framework for Declarative Agentic AI in Business Process Analysis." arXiv:2606.15291, 2026. https://arxiv.org/abs/2606.15291
23. Khattab, O., et al. "DSPy: Compiling Declarative Language Model Calls into Self-Improving Pipelines." arXiv:2310.03714, 2023. https://arxiv.org/abs/2310.03714
24. Sutton, R. S. "The Bitter Lesson." 2019. http://www.incompleteideas.net/IncIdeas/BitterLesson.html
25. De Giacomo, G., Kampik, T., Kirchdorfer, L., Montali, M., and Weinhuber, C. "Formal Foundations of Agentic Business Process Management." arXiv:2604.17347, 2026. https://arxiv.org/abs/2604.17347