Skip to main content

Concept map

DIAL has many moving parts — Core, adapters, applications, toolsets, interceptors, and the UI layers around them — and the names alone do not reveal how they fit together. This page is a visual and narrative map of those relationships. It is written for architects and developers who have read What is DIAL and want a single picture of the platform before diving into any one part. For one-line definitions of every term used here, see the glossary.

One required component, everything else optional​

The central idea of DIAL is that DIAL Core is the only mandatory component. Every request goes through Core, in one of its AI APIs: the Unified API, OpenAI Responses, or Anthropic Messages. Everything else — the chat UI, the admin panel, adapters, applications, interceptors — plugs into Core or sits in front of it. This is why the concept map is best read as concentric layers radiating out from Core, rather than as a flat list of features.

The diagram below shows those layers. Color marks the component category, and the same scheme is reused in the diagrams that follow: Core is blue, the optional UI layers (DIAL Chat, DIAL Admin, DIAL Overlay, and the SDKs) are green, provider integration through adapters is orange, and external systems are gray.

Inside DIAL Core​

DIAL Core is itself made of a few major parts. Its AI APIs are the entry point. Deployments expose models, applications, and interceptors, while aliases and routers put a stable name or a per-request model choice in front of them. Toolsets, resources, and access control round out what Core manages.

How the building blocks compose​

The platform's power comes from composition: most concepts are building blocks that snap together through DIAL Core. Three chains carry most of that composition — wrapping a provider model, defining an application from a template, and reaching external services through a toolset:

Reading from the smallest unit outward:

  • An adapter wraps an external provider model so DIAL Core can call it. Once wrapped, a model is just another deployment in Core.
  • An application is also a deployment. Because applications and models are both deployments that Core calls by name, an application can call a model — or another application — the same way. This interchangeability is the basis of the agentic platform.
  • Schema-rich applications are defined by an application type. The standard types — Quick App and Code App — let end users create applications without writing code.
  • A toolset connects an application to external services through an MCP server. Quick Apps use toolsets to reach beyond the model.
  • An interceptor sits in the request path of a deployment, modifying requests or responses — for example, redacting PII before a prompt reaches a model.

The UI layers reuse the same blocks rather than introducing new ones. Agent builders in DIAL Chat are wizards over application types; the Catalog lists deployments the user can access; and DIAL Overlay embeds Chat into another web application without rebuilding any of it.

One canonical name per concept​

Several concepts in DIAL carry more than one name across source code, UI labels, and informal speech. The glossary resolves each to a single canonical term. The most important example is the agent builder: it appears as "application runner" in source code, "application builder" in the Chat UI, and "builder" in the Admin sidebar. Documentation uses agent builder everywhere. When a diagram or page seems to introduce a new concept, check the glossary first — it is often an existing one under a different label.

Further reading​

  • Glossary — canonical definition of every term in this map
  • Architecture highlights — how these components behave at runtime
  • DIAL Stack — the concrete services and dependencies behind these concepts
  • Agentic platform — why composing models and applications through DIAL Core is the core design choice