During development
Build and check your code
Your team and AI agents work from the same Glages model. Requirements, tests, and implementation checks share the same business logic.
Build applications and
automation with AI agents
using ready-made Glages
business process models
02The product
One model for your code,
your team, and AI
Don’t rebuild standard business logic from scratch. Start with a process model that defines its rules, data, actions, and outcomes in a form software can check.
Glages model
Business logic at the heart of your product
Data
Rules
Actions
Results
At runtime
Keep operations under control
Your application applies that model to current data, checks actions before execution, and stops when the required conditions are not met.
What a Glages model defines
The structure behind a process:
Entities and relationships
The objects in a process and how they relate
States and transitions
What can change, and under which conditions
Data and sources
Required facts and acceptable sources
Rules and constraints
What is allowed, what is blocked, and for whom
Actions and outcomes
Available operations and their possible results
Stop conditions and traces
When to stop, and what evidence to record
03Reliable automation
AI actions, governed by a Glages model
AI interprets a request and proposes an action. Your application checks it against the Glages model and current data before execution. An agent’s suggestion is not permission to move money or change an order.
Block invalid operations
Your application blocks actions that violate the model’s rules before they happen—not after the damage is done.
Don’t turn guesses into actions
Missing a required fact? The operation stops. The system identifies what is missing instead of choosing the most likely answer.
Make decisions traceable
Recorded data, checks, and decision reasons help your team understand why an action was allowed or stopped.
Before an action runs
AI proposes an action
For example, issue a refund
Your application checks it
Glages model + current data
Allowed
Required conditions are met. The operation may proceed.
Blocked
The operation does not run. The reason is recorded.
Needs information
Execution waits for missing facts or a reliable status.
An external service failure is recorded separately. It is not a business-rule rejection.
Not just instructions for AI. Rules enforced by software
To keep AI actions under control, developers make model checks a required part of the application’s execution path. Every governed operation must pass through them. Putting a model in a prompt is not the same as enforcing its rules in software.
04Glages in practice · Illustrative scenario
The payment service timed out
Should you refund again?
The customer paid $2,000. A partial refund of $800 was approved. Another $800 may stay below the original payment—but would pay the same refund twice.
One agent already submitted the refund but received no response. The customer follows up through another channel—and a second agent is ready to send it again.
Checked against the Glages model
No response doesn’t mean no refund
The application checks the original operation first. It won’t authorize a new payout while the outcome is unknown.
Refund confirmed
Don’t pay it again
Pending or outcome unknown
Resolve the status. Don’t create a new payout
Original attempt definitively failed
Recheck eligibility before another attempt
Two agents. One consistent refund process
One Glages model defines the rules for both agents—from development through runtime.
Implementation details
Use one business-refund ID and durable shared state across channels. Check eligibility and register an attempt atomically, so two agents cannot both pass the same check.
A network retry belongs to the original operation; it is not a new payout. Persist the idempotency key and parameters before sending, and respect the provider’s contract and key-retention window.
Reconcile the original result through the API or authenticated provider events, handling duplicates and late arrivals. Confirmed pending and unknown are distinct states, though neither permits a new payout. Escalate unresolved outcomes rather than sending another payment.
05Time and cost savings
Spend less on development, AI, and maintenance with Glages
Use Glages models to build and check code with AI agents. After launch, run routine business logic in conventional software—not through unnecessary LLM calls.
01Development
Less logic to rebuild
Rules, required data, and modeled process variations are defined in Glages. Use that foundation in an application or workflow, then reuse it in other compatible projects.
02Validation
Less rework and manual checking
Code, requirements, and tests share one model. Checking an implementation against it helps identify violations of business rules before launch.
03AI usage
Lower token usage
Conventional code handles routine rules. Where that replaces LLM calls, token usage falls. Keep AI for interpretation and generation—not for reconstructing the rules.
CodeProcess rules
AIInterpretation and generation
04Maintenance
Easier to maintain and change
The model preserves process rules and constraints. The next developer or agent gets code with its context, without having to rediscover how the process works.
06Models & use cases
Glages models — from one workflow to a business domain
Start with a single task or connect multiple workflows in your application. Choose a relevant example, then talk with us about model scope and availability.
Choose the scope of your project
A business-domain model connects multiple workflows and the rules that keep them in sync.
A process model covers an individual workflow and can be reused across compatible projects.
01 / 10Explore the examples
Business domain
E-commerce
Connect orders, payments, fulfillment, and customer service.
Example workflows
- Orders & payments
- Inventory & shipping
- Returns & refunds
Example dependency
Discuss this domain
Once an item has shipped, the available actions change: a return workflow replaces a simple cancellation.
Business domain
Hospitality
Connect reservations, payments, and room readiness.
Example workflows
- Reservations
- Check-in & access
- Check-out & settlement
Example dependency
Discuss this domain
A reservation alone does not authorize check-in: dates, payment, guest identity, and room readiness also matter.
Business domain
Logistics
Coordinate handoffs, delivery, and exception handling.
Example workflows
- Receiving & shipping
- Delivery
- Claims
Example dependency
Discuss this domain
Creating a label does not confirm a carrier handoff: the status change needs the appropriate evidence.
Business domain
Property management
Connect agreements, access, and property maintenance.
Example workflows
- Agreements & billing
- Access
- Maintenance requests
Example dependency
Discuss this domain
Renewing or ending an agreement needs coordinated changes to access rights and related obligations.
Business domain
Auto repair
Connect diagnosis, estimates, approved work, and vehicle handover.
Example workflows
- Diagnosis & estimates
- Repairs & parts
- Acceptance & payment
Example dependency
Discuss this domain
Finding another fault does not authorize a higher bill: additional work requires its own approval.
Business domain
Insurance workflows
For a defined insurance line, coverage scope, and applicable rules.
Example workflows
- Claims intake
- Evidence & coverage
- Decision & payout
Example dependency
Discuss this domain
A payout depends on confirmed coverage, evidence, and the claim decision—not just the amount requested.
Business domain
Construction projects
Coordinate project milestones, changes, and payments.
Example workflows
- Milestones & changes
- Work acceptance
- Invoices & payments
Example dependency
Discuss this domain
A milestone payment depends on the required acceptance evidence, not just a report that the work is complete.
Business domain
Clinic administration
Coordinate appointments, documents, and billing—not clinical decisions.
Example workflows
- Appointments
- Documents & consent
- Billing & settlement
Example dependency
Discuss this domain
An appointment does not establish that required documents and consent are in place; these remain separate conditions.
Business domain
Accounting operations
Connect records, approvals, and settlement under a defined accounting scope.
Example workflows
- Source documents
- Reconciliation & approval
- Invoices & settlement
Example dependency
Discuss this domain
A paid invoice and a settled obligation are different states: a reconciliation mismatch requires its own resolution.
Business domain
Service & repair
Coordinate requests, approved work, and completion evidence.
Example workflows
- Requests & estimates
- Work & materials
- Acceptance & warranty
Example dependency
Discuss this domain
A technician finishing the job and a customer accepting it are separate events with different consequences.
Process model
Payments
Link a payment to an obligation and confirmation from the required source.
What the model defines
- Amount & payee
- Confirmation
- Operation outcome
Example rule
Discuss this process
A message saying “I paid” does not replace confirmation from the payment service.
Process model
Refunds
Check eligibility, the permitted amount, and prior refund attempts.
What the model defines
- Eligibility
- Amount & history
- Permission or hold
Example rule
Discuss this process
An unknown result from the first attempt does not authorize a second payout for the same obligation.
Process model
Delivery
Determine available actions from the current shipment state.
What the model defines
- Shipment & handoff
- Delivery evidence
- Exceptions
Example rule
Discuss this process
Changing an address after carrier handoff needs a different workflow from a change before shipping.
Process model
Reservations
Track resource availability, holds, and expiration.
What the model defines
- Resource & time slot
- Hold
- Confirmation or release
Example rule
Discuss this process
Concurrent requests must account for active holds, not just the resource’s original availability.
Process model
Approvals
Tie approval to an authorized person and a specific request version.
What the model defines
- Approval scope
- Authority
- Decision & conditions
Example rule
Discuss this process
Approval of an earlier estimate does not authorize a new amount or a different scope of work.
Process model
Document checks
Define required records, accepted sources, and validity conditions.
What the model defines
- Required information
- Source & validity
- Discrepancies
Example rule
Discuss this process
Having a file does not establish that the document is valid or applies to this case.
Process model
Claims handling
Keep requests, evidence, and compensation tied to the same case.
What the model defines
- Requests & evidence
- Decision history
- Compensation
Example rule
Discuss this process
Two contacts about the same claim must not automatically create two compensation payments.
Process model
Repairs
Connect diagnosis, authorized work, and acceptance.
What the model defines
- Diagnosis
- Approved work
- Acceptance
Example rule
Discuss this process
Work outside the approved estimate requires new authorization—not an AI assumption.
Process model
Invoicing
Connect the basis for an invoice, its amount, and the underlying obligation.
What the model defines
- Basis & amount
- Issue & adjustment
- Settlement status
Example rule
Discuss this process
A repeated completion message must not, by itself, create a second invoice for the same milestone.
Process model
Changes to obligations
Track which terms apply after an agreed change.
What the model defines
- Current terms
- Agreed change
- Updated obligations
Example rule
Discuss this process
New dates or amounts must consistently replace earlier terms across the affected workflows.
Different domains. Shared processes
Payments, reservations, and document checks recur across industries. The Glages factory reuses compatible process models to build business-domain models, rather than rebuilding the same logic.
For your team
Software teams
Build vertical software, AI products, CRM, ERP, and self-service applications on shared business logic.
Systems integrators
Build solutions for different clients on a reusable foundation. Focus on integrations and client needs rather than formalizing the same processes again.
Internal teams
Connect existing systems into governed workflows with explicit execution conditions, constraints, and reasons to stop.
Have a different workflow in mind?
Tell us about your project. We’ll discuss the right model, the scenarios it needs to cover, and what’s available to get started.
07Getting started
Start with one workflow
See what Glages changes
Choose one workflow in your application or automation. Use it to evaluate the work a model can reduce and the operations it can help control.
Tell us what you’re building
Which systems and AI tools do you use? What matters most: development time, AI costs, or operational reliability? A short description is enough to start.
Find the right model
We’ll assess fit and integration requirements, then agree on availability, terms, and the scope of the first project.
Evaluate the result
Your team applies the model to the chosen workflow. Agree on the comparison upfront: development time, rework, token usage, or rule compliance.
Evaluate one workflow first. Expand based on evidence.
Let’s talk08Models and licensing
License a Glages model for what you’re building
License a specific Glages model as a foundation for developing and running your applications and automation.
From a single process to a business domain
A model can cover one process, such as a refund, or a connected set of processes: ordering, payment, fulfillment, and returns.
We’ll identify a model for your project. If no suitable model is available, we can discuss the feasibility, scope, and timing of a new release.
Glages Model Factory
A production and verification process behind every model
Glages Model Factory is our system for producing reusable models. The approach combines reusable components, formal checks, and an assessment of coverage for the declared scope. New models build on existing components, tests, and fixes.
ComponentsChecksModel
For your company
An annual license for the selected model
For your product
An OEM license to embed a model in your application or platform
For multiple projects
Use a model across products or client solutions
Clear terms before you start
Agree upfront on the model, permitted uses, pricing, updates, and support.
09Questions, answered
What to know about Glages Models
Is this another AI model or agent?
Glages models are not neural networks. They define business processes and their rules in a machine-checkable form. They do not replace your agent; they define the process and boundaries it can work within.
How is a model different from written instructions?
A document needs interpretation. A model expresses rules and conditions in a form software can check. With controlled execution, the application checks whether an operation is allowed—not just the agent that proposed it.
Does a model guarantee zero errors?
No. Control applies to the formalized rules and integrated operations. Models, data, integrations, and external services can still have defects. The goal is to block actions that violate the model and distinguish business outcomes, missing information, and execution failures.
Can we use existing code and our preferred AI tools?
The approach supports incremental adoption and integration through the model’s interface. Compatibility with specific languages, agents, and tools must be checked for the selected model and usage mode.
How does it account for our company’s requirements?
Your application connects its own data, systems, and model-supported parameters. If a process falls outside the model’s scope, we assess whether another model or version is needed. Agents must not invent missing business rules at runtime.
Does AI need to stay in the application?
Not necessarily. You can use AI only during development. At runtime, conventional software, external services, people, or agents can carry out the process within the model’s requirements.
Can we get started now?
We can discuss your project and a potential pilot. Glages is in development; availability, tooling, and timelines are determined for each model.
Are the use-case cards available models?
The cards illustrate potential applications. We assess whether a suitable released model exists, what it covers, and what your implementation would require.
10Let’s talk about your project
What do you want to build faster—and automate more reliably?
Tell us what you’re building and where you use AI. We’ll discuss a suitable use case, integration requirements, and how to evaluate a pilot.
A short description is enough. Please don’t include confidential information.
What are you working on?
Selected use case