Inside the Asgard ecosystem: the closed loop from insight to execution
Explore the core architecture behind enterprise automation. See how Mimir (decisions), Odin (enablement) and Sindri (execution) work together to build AI productivity that scales.
Asgard
Platform overview
- The method comes out of real deployments
- Cloud or on-premises
- Every model call is recorded
What an agent needs
What makes an agent usable
Company knowledge
The agent follows your way of working
Procedures, rules and how experienced staff actually work, written down so an agent follows your way of working.
- Knowledge base
- Skills
Data
Every agent returns the same number
Read-only connections to ERP and POS. Revenue and yield are defined once, so every agent returns the same number.
- Data Connector
- Semantic model
Operating the systems
Systems without an API can be operated too
Use the API or MCP where there is one. For older web systems without one, the agent drives a browser (Computer Use).
- MCP tools
- Computer Use
Permissions and approval
The agent stops for approval before changing data
Who may use which agent and what it may read or write are granted one by one. The agent stops for approval before changing data.
- Management Console
- Governance gate
- Release approval
Models and spend
Usage is visible for every key
Which group holds each key and what it is for, which models it may call, how many tokens a month, and how many it has used.
Continuous correction
Wrong answers become test questions
Wrong answers come back as test questions. A fix ships only when the score improves.
- Evaluations
- Routines
Architecture
Product architecture
Ecosystem
- Yggdrasil
Open-source MCP servers and skills, MIT
Integration and custom build: Asgard and SI partners on one platform
- Custom integration
In-house systems, customer support
- Heimdall
Media & PR AI
- Freyr
Multi-brand commerce AI
- Yggdrasil
Core modules
- Odin builds
Compose agents, connect data
- Sindri runs
Staff run agents, and approve
- Mimir answers
Ask data in plain language
- Odin builds
The ontology layer
Where the agent learns your business
- Knowledge base
Wiki, reference tables, history
- Semantic model
Defined once, shared everywhere
- Skills
Procedures the agents share
- Auto sync
Updates, no redeployment
- Knowledge base
Agent runtime
- Isolated workspace
One per job
- Computer Use
Web systems with no API
- MCP tools
For systems with APIs
- Schedules and triggers
On a timer or on an event
- Isolated workspace
Governance
Users and agents
- Management Console
Who may use what
- Governance gate
Asks before writing
- Release approval
Checks, then you approve
- Conversation scan
Weekly leak check
Models and tokens
- Tyr
Keys, purpose, spend
- Management Console
Models
- Tyr, one endpoint
Agents, internal systems and coding tools connect here
- Many vendors
Claude, GPT, Gemini, Kimi, or bring your own key
- Switch models, no code change
Route around a bad vendor
- Usage and cost in one place
Blocked when the quota is spent
- Tyr, one endpoint
Demonstration project
Retail demonstration project: from a store shortage to an inter-store transfer
- 01
The situation: the flagship store runs out tomorrow
Sunday evening, the flagship store has 6 co-branded flasks left after selling 45 that day. On the normal process, the transfer request waits for Monday's meeting, about two days out. - 02
Odin: semantic models and agents
POS, WMS, ERP, e-commerce, suppliers and CRM, plus the data warehouse, get seven semantic models. Odin also builds five agents. The semantic models are query-only. One deployment created 69 resources in 46 seconds. - 03
Sindri: the agent reads the skill before it queries the stock
The agent first reads the transfer skill to learn how transferable quantity is calculated, then queries the stock. Up to 102 units can be transferred across the network. It only reads and changes nothing, so it does not stop for approval. - 04
Sindri: a transfer request waits for approval
Before creating a transfer request, the agent stops for approval. The options are allow for this conversation, allow once, or deny. Three transfer requests, 86 units in total, are approved one at a time and then created. - 05
Mimir: one question shows who can send stock
An executive asks Mimir about stock at each store. 11 stores hold a surplus, and Banqiao and Zhubei alone hold 92 units. The chart can be saved to a dashboard.
This project was built on the platform following the rollout. The scenario and numbers are simulated demonstration data. The agents, semantic models and approval gates are genuinely built and published.
- 1 · DiscoveryFDE
- The FDE team interviews your team and collects how your company works and its documents.
- 2 · Ask the AI consultantFDE
- The FDE team asks the AI consultant to put these documents onto the Asgard Platform. The AI consultant is a coding agent with asgard-cli loaded.
- 3 · Write the settingsAI consultant
- The AI consultant reads the LLM Wiki in asgard-cli. Then it writes your procedures as agent settings. The settings are stored in your Asgard workspace.
- 4 · DeployAI consultant
- The AI consultant deploys the settings to Asgard Platform.
How it connects
Product connections
- PublishingOdin → Sindri, Mimir
- Every Odin project has an Applications tab listing what it has published. Agents go to Sindri; semantic models go to Mimir.
- Accounts and rolesManagement Console
- Workspace members are managed in the Console. Each product has its own accounts and roles, which decide who can use which resource.
- Billing and usageFehu
- Plans, payments, usage reports and the Credit wallet, in one place.
- Where people use itChannels
- Agents can sit in Sindri, or connect to LINE, Slack and other chat apps, a REST API, or a website through the JS SDK.