Skip to main content
Odin | Asgard Studio is the core build tool of the Asgard AI platform, used to create AI Agents, wire up tools and knowledge bases, and publish the results to other Asgard products such as Mimir and Sindri.

About Odin | Asgard Studio

Odin | Asgard Studio is the core build tool of the Asgard AI platform, used to create AI Agents, wire up tools and knowledge bases, then publish the results to other Asgard products such as Mimir and Sindri.

The platform is organized as workspaces containing projects. A workspace roughly corresponds to a company or a team, while projects are the independent product lines or applications beneath it. The actual build work happens at the project level, and each project has its own set of Agents, tools and data configuration.

Workspaces and projects each have their own overview page. The workspace-level overview is an analytics dashboard covering requests per second, request duration, completion model and embedding model token usage, total messages and other metrics, filterable by project. The project level has a separate statistics panel scoped to that single project.

Building AI Agents​

Odin offers two ways to build an Agent, suited to different levels of complexity. Managed Agent is the more direct approach: once you've set the role and system prompt, you can mount external tools (MCP Servers), reusable skill packages (Skillsets), files and knowledge bases (Drive), and structured data models (Semantic), which lets the Agent actually query data and call external systems. When you're done you can open a chat window alongside to test the replies, without having to publish it first to verify anything.

Flow Agent is for more complex processes. Instead of typing out a role, you drag nodes (entry, exit, processing steps) to assemble a full set of decision and execution logic like drawing a flowchart, which suits situations needing multi-step decisions or coordination across several subtasks. Once built, you can publish it as a named version before it goes live, making it easier to track how each version actually behaves.

Setting up automation​

Beyond conversational Agents, Odin also supports packaging a fixed sequence of work into reusable automation, in three forms distinguished by how they're triggered.

Automation Tools wrap a commonly used sequence into a function other processes can call directly, instead of reassembling the same logic every time. They use the same visual editor as Flow Agent, the difference being that an Automation Tool is a component referenced by other processes rather than an Agent exposed on its own, which suits extracting recurring substeps for shared use (a particular format conversion, say, or a fixed piece of query logic).

API wraps a process as a set of HTTP endpoints so external systems can hit a URL to trigger backend or AI-side processing, without going through a conversational interface. This suits treating logic built in Odin as a service, plugged into existing systems or scheduled jobs, with the external program deciding when to call it and what parameters to pass.

Trigger works the other way around: Odin schedules and runs it itself, on a cron-like timer, with no external system or user needing to start it. The list screen also shows how many conversations are currently waiting on a user, which makes it easy to see which automations are stuck at a human step, so a schedule that finished running but actually stopped at a node needing manual confirmation doesn't go unnoticed.

Preparing the AI's toolbox​

Getting an Agent to actually do work usually means preparing reusable components first, rather than assembling everything from scratch for each new Agent.

MCP Servers are the standard interface for Agents to reach external systems, fetch data and call tools, following the Model Context Protocol (MCP). You can create an MCP Server directly from an existing workflow, wrapping that process as an externally callable tool, and you can also go the other direction and connect an already-running third-party MCP server so Agents can use what it offers. Both directions are supported.

Skillsets are reusable bundles of skills, designed from the start to share one set of capabilities across multiple Agents rather than reimplementing it for each. Besides being mounted for Agents to use, they also support manual execution, and each run records its status, duration and timestamp, which makes it easy to check afterwards whether a particular run succeeded or where it got stuck.

Plugins are the packaging unit one level up, combining tools (Toolsets), skills (Skillsets), file stores (Drive), data models (Semantic) and a Managed Agent into a single whole. The point is this: if the same set of resources often needs mounting together on different Agents, rather than attaching them one by one each time, package them as a Plugin and mount the whole thing, which also makes it harder to miss a resource. You can edit the configuration while building one, or switch to read-only mode to simply inspect its contents.

Drive is a shared file and knowledge space across Agents, with its own sync mechanism ensuring that everywhere referencing the same Drive sees consistent content. Besides being mounted as a queryable knowledge source for Agents, it can also be embedded directly into other pages or systems through an iframe.

Managing data and knowledge​

Semantic builds structured data models so Agents can query an organization's internal data, rather than answering only from text sitting in files.

Worth noting: these models aren't used by Odin alone. They're also what Asgard's data analytics product Mimir (branded 資料洞察, Data Insight) actually operates on, and both sides see the same model.

Knowledge Base is a complete knowledge ingestion pipeline. Once a knowledge base exists you can add sources, configure scheduled updates (a web crawler, say, or periodic database sync), then process CSV, Excel, JSON and other file formats and chunk them according to your settings.

The AI then adds tags and supplementary descriptions automatically, and finally you can proofread each source chunk by chunk to make sure what lands in the knowledge base is accurate.

Connecting to other Asgard products​

What you build in Odin isn't confined to Odin. Every project has an Applications tab listing what that project has published to other Asgard products, and clicking a card jumps straight to the corresponding standalone application.

Agents published for Sindri (branded Agent Hub) appear here, and Odin also lets you configure Agent Hub rules that apply to the whole project, such as which AI models are available and the working directory shared between conversations.

Data models published for Mimir (Data Insight) are likewise listed on this tab.

Put another way, Odin handles building, while Sindri and Mimir are where those results are actually seen and used. The three products deploy independently but are wired together through publishing.

Basic settings​

The project level also has a set of lower-level settings governing the foundational resources shared across the whole project, rather than the configuration of a single Agent or process. Here you configure connections to external systems (authorized over OAuth), choose the completion model (which generates replies) and the embedding model (which computes similarity and powers vector search), and set up data sources. These settings are shared by the Agent, Automation and Knowledge Base features described above.

Common use cases​

  • Chatbots
  • Digital assistants
  • Internal custom search engines
  • Training and education applications
  • Image recognition
  • Internal enterprise automation (approvals, notifications, data processing)